From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-f193.google.com (mail-lj1-f193.google.com [209.85.208.193]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 826E0452566 for ; Sat, 16 Nov 2019 23:43:08 +0300 (MSK) Received: by mail-lj1-f193.google.com with SMTP id d5so14402981ljl.4 for ; Sat, 16 Nov 2019 12:43:08 -0800 (PST) From: Georgy Kirichenko Date: Sat, 16 Nov 2019 23:43:06 +0300 Message-ID: <2837770.45GMzVBpIU@home.lan> In-Reply-To: <20191116103755.GC14490@atlas> References: <20191114125705.26760-1-maria.khaydich@tarantool.org> <3021966.aeNJFYEL58@home.lan> <20191116103755.GC14490@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 Saturday, November 16, 2019 1:37:55 PM MSK Konstantin Osipov wrote: > * Georgy Kirichenko [19/11/15 22:59]: > > > 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. > > Fine, that might work - given the vector clock this how it will > naturally work in most cases. Too bad you kept it a secret until now. > > > > 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. > > Ehm, where's the link? Or tarantool is now closed source? Sharing > it publicly would have allowed me collaborate - which you seems to > intentionally want to avoid. There is no link because this is just a research which would be shared when it have some proofs. I definitely do not want to pollute the public mail list. And having many-turns responded RFCs is not good for communication as it erodes the initial topic. > > > > 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. > > Well, this is not because of any lack of intent on my part. Going > back to the patch, it doesn't look good so far. Sorry, but you have written: "This is well designed in my view" which I accepted with proud. The only you complain was about the garbage collection. And you did not respond anything to my last patch. > If you wanted to > change my opinion, the best course of action is to use technical > arguments (and RFC is the best way for it), not some ungrounded > claims about better processes or how to best contribute to an open > source project. > > > > Whatever it is needed for may never happen - and even if it > > > happens, it is most likely the wrong thing to do.