From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-f178.google.com (mail-lj1-f178.google.com [209.85.208.178]) (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 10FC2452566 for ; Sat, 16 Nov 2019 13:37:57 +0300 (MSK) Received: by mail-lj1-f178.google.com with SMTP id d5so13375914ljl.4 for ; Sat, 16 Nov 2019 02:37:57 -0800 (PST) Date: Sat, 16 Nov 2019 13:37:55 +0300 From: Konstantin Osipov Message-ID: <20191116103755.GC14490@atlas> References: <20191114125705.26760-1-maria.khaydich@tarantool.org> <14579640.zJlKmNO63O@home.lan> <20191115135704.GA7713@atlas> <3021966.aeNJFYEL58@home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3021966.aeNJFYEL58@home.lan> 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: Georgy Kirichenko Cc: tarantool-patches@dev.tarantool.org * 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. > > 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. 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. -- Konstantin Osipov, Moscow, Russia