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 E4D7A469710 for ; Tue, 26 May 2020 14:41:36 +0300 (MSK) Received: by mail-lj1-f193.google.com with SMTP id k5so24018837lji.11 for ; Tue, 26 May 2020 04:41:36 -0700 (PDT) Date: Tue, 26 May 2020 14:41:34 +0300 From: Konstantin Osipov Message-ID: <20200526114134.GA4651@atlas> References: <20200525163409.GC4272@atlas> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Subject: Re: [Tarantool-patches] [PATCH v2 2/2] wal: reorder tx rows so that a tx ends on a global row List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Serge Petrenko Cc: tarantool-patches@dev.tarantool.org, v.shpilevoy@tarantool.org * Serge Petrenko [20/05/26 12:42]: > > 25.05.2020 19:34, Konstantin Osipov пишет: > > * Serge Petrenko [20/05/25 14:00]: > > > > While I think it's an acceptable strategy for a bugfix, I still > > think relaying has to be fixed to be transactional, the current > > xstream api is a huge legacy we're stuck with since Tarantool 1.3! > > > > It saddens me a great deal the relay patch may be shuffled into > > the desk once the problem is not as urgent. > Hi! Thanks for your  answer. > I understand your concern with transactional relay rework. However, this > approach faces some non-trivial problems we discussed verbally. That's why > I chose a more simple solution. > > > I have a question regarding this patch. Do you think I should reorder the tx > rows > so that the last row is a global one? Maybe it'd be better to just set > is_commit > flag on the last global row? This breaks tx boundaries in local WAL, but > preserves > them as is in replication and in other instances' WALs. I don't think we'll > need tx > boundariesin local WAL anyway, but still breaking the invariant that the > last tx > row has an is_commit flagset to true is scary. We will eventually need tx boundaries everywhere, it's just a rakes waiting to be stepped on that we added transaction boundaries but did not enforce them everywhere. If you set is_commit flag on the last global row, you will exclude local rows from the transaction locally. Reordering, but more specifically, simply moving the last global xrow to the end of the transaction list, is safer IMHO. -- Konstantin Osipov, Moscow, Russia