[Tarantool-patches] [PATCH v2 1/5] box: introduce matrix clock

['Konstantin Osipov']

* Timur Safin <tsafin at 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