From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-f196.google.com (mail-lj1-f196.google.com [209.85.208.196]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id D96CE469719 for ; Thu, 19 Mar 2020 11:17:29 +0300 (MSK) Received: by mail-lj1-f196.google.com with SMTP id z10so530501ljn.0 for ; Thu, 19 Mar 2020 01:17:29 -0700 (PDT) Date: Thu, 19 Mar 2020 11:17:27 +0300 From: Konstantin Osipov Message-ID: <20200319081727.GA5707@atlas> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Tarantool-patches] [PATCH v2 0/5] replication: fix local space tracking List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Serge Petrenko Cc: v.shpilevoy@tarantool.org, tarantool-patches@dev.tarantool.org * Serge Petrenko [20/03/18 22:52]: > https://github.com/tarantool/tarantool/issues/4114 > https://github.com/tarantool/tarantool/tree/sp/gh-4114-local-space-replication > > The patchset contains 2 of Georgy's patches perorming WAL gc rework. > The first patch introduces a matrix clock structure, which contains the latest > known vclocks of all the cluster members and can be used to build a vclock, > which is less than or equal to all the member vclocks. > Such a vclock is used then in the second patch, where gc is rewritten to stop > tracking needed WAL files by vclock signature. Now replica vclocks are used to > define which files are still needed. One more follow up. While I don't like the approach with matrix clock, I accept there may be an issue with the current way GC subsystem tracks replicas. Could you add issue description to the changeset comment? What's the problem with using clock signature to keep track of relays? And if there is an issue with gc signature, let's switch to vclocks instead, but why build a matrix? -- Konstantin Osipov, Moscow, Russia