[Tarantool-patches] [PATCH] Trigger on vclock change

[Georgy Kirichenko]

On Saturday, November 16, 2019 2:56:07 PM MSK Konstantin Osipov wrote:
> * Georgy Kirichenko <georgy at tarantool.org> [19/11/15 22:59]:
> > Please, point me out first how your claims related to my approach. Because
> > you made no effort to understand the approach. Even did not ask for very
> > brief explanation.
> 
> Alright, you claim I am not asking for a brief explanation. I am
> asking for an RFC, which is the best way to explain ideas we have.
Yes, of course, the RFC is the best way to explain my ideas, but today I have 
only a proof of concepts which requires some further investigation to 
understand how can I implement it (as I pretty sure the RFC should contain an 
implementation plan). Just after еhe raw patch would be working I definitely 
will write a RFC and any other documentation. The only thing I asked you to 
discuss this proof of concept with you as the research is not done yet.
> 
> But fine, I am asking you:
> > > If you have a miracle design, and you happen to not want to send
> > > an RFC, you still can prove it by sending a patch.
> > 
> > The next wrong suggestion. I have a concrete design which was shared and
> > discussed.
> > 
> >  > Last time it didn't work: your refused to send an RFC for in-memory WAL
> >  > -
> > 
> > and the patch can't pass the code review for over 3 months.
> > Please read my previous message and find out why this patchset is on hold.
> > To be concrete, the patch is not passed the review because of:
> > 1. Bad gc design which I want to fix first, and I already answered why
> > your
> > approach to fix it is not even working. Yes, you could not / did not want
> > to object.
> 
> What is wrong with GC and how exactly do you want to "fix" it?
We have discussed some points with you verbally (about 3-4 month ago).
The main point is: the way of information processing is weird:
1. WAL has the full information about the wal directory (xlogs and their 
boundaries)
2. WAL process the wal directory cleanup
3. We filter out all this information while relaying (as a relay has only a 
stream of rows)
4. We try to restore some of this information using on_close_log recovery 
trigger.
5. We send recovered boundaries to TX and tx tread reconstruct the relay order 
loosing really relay vclocks (as they mapped to the local xlog history)
6. TX sends the oldest vclock back to wal
7. There is some issues with making a consumer inactive. For instance if we 
deactivated a consumer could survive, for instance if deleted xlog was already 
send by an applier but not reported yet (I do not even know how it could be 
fixed in the current design).
Maybe it is working, but I afraid, this was done without any thinking about 
the future development (I mean the synchronous replication). Let me explain 
why.
1. WAL should receive all relay states as soon as possible.
2. The set of relay vclocks is enough to perform garbage collection (as we 
could form a vclock with is the lower bound of the set)
So I wish the garbage collection would be implemented using direct relay to 
wal reporting. In this circumstances I was in need to implement a structure (I 
named it as matrix clock - mclcok) which able to contain relay vclocks and 
evaluate a vclock which is lower bound of n-members of the mclcock.
The mclock could be used to get the n-majority vclock as wel as the lowest 
boundary of all vclock alive.
The mclock is already implemented as well as new gc design (wal knows about 
all relay vclock and the first vclock locked by TX - checkpoint or join read 
view).