Tarantool development patches archive
 help / color / mirror / Atom feed
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

  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