From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp39.i.mail.ru (smtp39.i.mail.ru [94.100.177.99]) (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 31BC5469710 for ; Tue, 26 May 2020 15:08:36 +0300 (MSK) References: <20200525163409.GC4272@atlas> <20200526114134.GA4651@atlas> From: Serge Petrenko Message-ID: Date: Tue, 26 May 2020 15:08:35 +0300 MIME-Version: 1.0 In-Reply-To: <20200526114134.GA4651@atlas> Content-Type: text/plain; charset="utf-8"; format="flowed" Content-Transfer-Encoding: 8bit Content-Language: ru 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: Konstantin Osipov Cc: tarantool-patches@dev.tarantool.org, v.shpilevoy@tarantool.org 26.05.2020 14:41, Konstantin Osipov пишет: > * 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. > Ok, thanks. -- Serge Petrenko