From: 'Konstantin Osipov' <kostja.osipov@gmail.com> To: Timur Safin <tsafin@tarantool.org> Cc: tarantool-patches@dev.tarantool.org, v.shpilevoy@tarantool.org Subject: Re: [Tarantool-patches] [PATCH v2 1/5] box: introduce matrix clock Date: Thu, 19 Mar 2020 11:41:44 +0300 [thread overview] Message-ID: <20200319084144.GD5707@atlas> (raw) In-Reply-To: <09ba01d5fdc5$f5e1fab0$e1a5f010$@tarantool.org> * Timur Safin <tsafin@tarantool.org> [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
next prev parent reply other threads:[~2020-03-19 8:41 UTC|newest] Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-03-18 19:47 [Tarantool-patches] [PATCH v2 0/5] replication: fix local space tracking Serge Petrenko 2020-03-18 19:47 ` [Tarantool-patches] [PATCH v2 1/5] box: introduce matrix clock Serge Petrenko 2020-03-18 20:08 ` Konstantin Osipov 2020-03-19 8:11 ` Timur Safin 2020-03-19 8:41 ` 'Konstantin Osipov' [this message] 2020-03-19 9:17 ` Sergey Ostanevich 2020-03-19 11:28 ` Serge Petrenko 2020-03-19 11:56 ` Konstantin Osipov 2020-03-19 11:59 ` Serge Petrenko 2020-03-18 19:47 ` [Tarantool-patches] [PATCH v2 2/5] wal: track consumer vclock and collect logs in wal thread Serge Petrenko 2020-03-18 19:47 ` [Tarantool-patches] [PATCH v2 3/5] vclock: add an ability to set individual clock components Serge Petrenko 2020-03-18 20:10 ` Konstantin Osipov 2020-03-19 11:31 ` Serge Petrenko 2020-03-18 19:47 ` [Tarantool-patches] [PATCH v2 4/5] replication: hide 0-th vclock components in replication responses Serge Petrenko 2020-03-18 19:47 ` [Tarantool-patches] [PATCH v2 5/5] box: start counting local space requests separately Serge Petrenko 2020-03-18 21:12 ` [Tarantool-patches] [PATCH v2 0/5] replication: fix local space tracking Vladislav Shpilevoy 2020-03-19 8:17 ` Konstantin Osipov
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20200319084144.GD5707@atlas \ --to=kostja.osipov@gmail.com \ --cc=tarantool-patches@dev.tarantool.org \ --cc=tsafin@tarantool.org \ --cc=v.shpilevoy@tarantool.org \ --subject='Re: [Tarantool-patches] [PATCH v2 1/5] box: introduce matrix clock' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox