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

[Georgy Kirichenko]

On Friday, November 15, 2019 4:57:04 PM MSK Konstantin Osipov wrote:
> * Georgy Kirichenko <georgy at tarantool.org> [19/11/15 09:43]:
> > 90% of tarantool core developers are sitting together in one room or just
> > call-available during the day. Also, please, tell us how many RFC responds
> > you saw from a somebody who is not a part of tarantool core team. So, you
> > wish to force the whole team to use only this inconvenient and
> > unproductive (because of long-latency responds) communication way because
> > of your beliefs. So I have the another look: each thing to be discussed
> > should be discussed (or brainstormed) verbally (because we are the
> > tarantol TEAM members) first and only then a well-designed RFC could be
> > formed (or, maybe, you wish to have lots of worthless RFCs but I no see
> > any point here).
> 
> I gave earlier in this thread concrete examples how active-active
You made a mistake again. My approach is not about 
active-active. I did not ever claim that my patch will allow active-active 
(because we do not still have a transaction manager). When I said that any 
instance is able to commit I mean that any replica, which sees a majority, 
able to finalize a transaction (commit it) even if the transaction initiator is 
dead. 
> won't work. It didn't take me long. You chose to respond back with
> some vague claims and promises of magic.
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.
> 
> 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.
2. Vlad's comment about comments and naming. Please tell me how a miracle RFC 
could fix this issue (Yes, I am not very accurate with comments and texts)
3. Vlad comment about dynamic array allocation which I want to respond in the 
next version. I would like to repeat, I do not want to sent it until the first 
point will not be fixed.
4. Vlad's comments about some mess in my code (xlog_buf_begin and friends). 
They are already fixed but not shared because of the first point. And there is 
no way how a RFC could prevent it.

> 
> All this suggests that the patch by Maria is simply not worth it.
All this suggest that you have no clue how the patch would work in the future, 
seriously.
> Whatever it is needed for may never happen - and even if it
> happens, it is most likely the wrong thing to do.