From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp33.i.mail.ru (smtp33.i.mail.ru [94.100.177.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id CCC5E42F4C7 for ; Fri, 15 Nov 2019 22:57:53 +0300 (MSK) From: Georgy Kirichenko Date: Fri, 15 Nov 2019 22:57:52 +0300 Message-ID: <3021966.aeNJFYEL58@home.lan> In-Reply-To: <20191115135704.GA7713@atlas> References: <20191114125705.26760-1-maria.khaydich@tarantool.org> <14579640.zJlKmNO63O@home.lan> <20191115135704.GA7713@atlas> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [Tarantool-patches] [PATCH] Trigger on vclock change List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Konstantin Osipov Cc: tarantool-patches@dev.tarantool.org On Friday, November 15, 2019 4:57:04 PM MSK Konstantin Osipov wrote: > * Georgy Kirichenko [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.