From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-f194.google.com (mail-lj1-f194.google.com [209.85.208.194]) (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 1C0C5469710 for ; Fri, 29 May 2020 11:13:27 +0300 (MSK) Received: by mail-lj1-f194.google.com with SMTP id s1so1540301ljo.0 for ; Fri, 29 May 2020 01:13:26 -0700 (PDT) Date: Fri, 29 May 2020 11:13:24 +0300 From: Konstantin Osipov Message-ID: <20200529081324.GA164874@atlas> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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: Vladislav Shpilevoy Cc: tarantool-patches@dev.tarantool.org * Vladislav Shpilevoy [20/05/29 01:55]: > Alternative to relay - append a dummy NOP statement in the > end of the transaction, which would be global. But this is > also a crutch. I think the TSNs figuring out should be done > in relay. It could keep track of the current transaction, > change TSNs and is_commit when necessary. I think it's a good idea actually. Tweaking the relay is also a crutch. After all I wonder, what's so difficult in changing xstream api? Why do we need to invent these crutches? Thanks for pointing out the foreign key problem. -- Konstantin Osipov, Moscow, Russia