From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-f66.google.com (mail-lf1-f66.google.com [209.85.167.66]) (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 80AE0469719 for ; Thu, 19 Mar 2020 11:41:46 +0300 (MSK) Received: by mail-lf1-f66.google.com with SMTP id n13so908707lfh.5 for ; Thu, 19 Mar 2020 01:41:46 -0700 (PDT) Date: Thu, 19 Mar 2020 11:41:44 +0300 From: 'Konstantin Osipov' Message-ID: <20200319084144.GD5707@atlas> References: <680467d22cb2864fb4c2d18ac33c4cccb272ebbb.1584558067.git.sergepetrenko@tarantool.org> <20200318200846.GB17681@atlas> <09ba01d5fdc5$f5e1fab0$e1a5f010$@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <09ba01d5fdc5$f5e1fab0$e1a5f010$@tarantool.org> Subject: Re: [Tarantool-patches] [PATCH v2 1/5] box: introduce matrix clock List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Timur Safin Cc: tarantool-patches@dev.tarantool.org, v.shpilevoy@tarantool.org * Timur Safin [20/03/19 11:11]: > : > A matrix clock which allows to maintain a set of vclocks and > : > their components order. The main target is to be able to > : > build a vclock which contains lsns each one is less or equal > : > that n corresponding lsn from a matrix clock. > : > > : > The purpose of the matrix clock is to evaluate a vclock > : > which is already processed by wal consumers like relays > : > or to obtain a majority vclock to commit journal entries > : > in case of synchronous replication. > : > > : > @sergepetrenko: refactoring & rewrite comments to doxygen style. > : > : I think we have discussed that matrix clock should not be pushed. > : > : It's a huge over complication. > : > : Why are you committing this? > : > : -- > : Konstantin Osipov, Moscow, Russia > > That's the very good question. There is smell of some miscommunication > between parties involved, hopefully we will resolve it soon. > Last time we gathered to discuss sync replications, the consensus was > That we do not want matrix clock as they overcomplicate conflict resolution process (so, at least, it was not looking like prerequisite to sync > replications mechanism). George should clarify, but AFAIU his original design introduced matrix clock to GC and to sync replication. These series only touch the GC. George reported there was an issue with the current GC tracker, basically it becomes non-function when sync replication is in place -I don't know what the issue is. I'd love to discuss the problem first, and then see alternatives. The thing is, I'd like our vclock to become sparse one day and be able to contain thousands of entries. We could use a dynamic data structure which changes the underlying structure depending on the actual member count. To get there and stay efficient, we need to make sure we never copy entire vclock by value, and instead begin passing objects representing a "vclock diff" around. Maintaining a sparse matrix would be hell in this case. > Serge, if I miss some important detains here, I'd love to get corrected > here. I do feel there are some other reasons needed, which I probably > simply not aware of. -- Konstantin Osipov, Moscow, Russia