From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id C0803287BD for ; Mon, 11 Mar 2019 05:59:29 -0400 (EDT) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mhGRoWFmdGB2 for ; Mon, 11 Mar 2019 05:59:29 -0400 (EDT) Received: from smtp57.i.mail.ru (smtp57.i.mail.ru [217.69.128.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTPS id 7047E287BA for ; Mon, 11 Mar 2019 05:59:29 -0400 (EDT) Date: Mon, 11 Mar 2019 12:59:26 +0300 From: Konstantin Osipov Subject: [tarantool-patches] Re: [PATCH v3 1/2] Write rows without a lsn to the transaction tail Message-ID: <20190311095926.GA9866@chai> References: <48e024c9ada966ce68447a7cf24c201b1ebaf27b.1552248901.git.georgy@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48e024c9ada966ce68447a7cf24c201b1ebaf27b.1552248901.git.georgy@tarantool.org> Sender: tarantool-patches-bounce@freelists.org Errors-to: tarantool-patches-bounce@freelists.org Reply-To: tarantool-patches@freelists.org List-Help: List-Unsubscribe: List-software: Ecartis version 1.0.0 List-Id: tarantool-patches List-Subscribe: List-Owner: List-post: List-Archive: To: tarantool-patches@freelists.org Cc: Georgy Kirichenko * Georgy Kirichenko [19/03/11 09:55]: > Form a separate transaction with local changes in case of replication. > This is important because we should be able to replicate such changes > (e.g. made within an on_replace trigger) back. In the opposite case > local changes will be incorporated into originating transaction and > would be skipped by the originator replica. I wonder will we possibly have some recovery issues, since in fact we're performing a reordering of execution here? Imagine local and remote statements change the same set of rows. During initial execution these changes are intermixed, during recovery they are serialized. It seems we clearly have a problem here. We can either open a bug, support multiple txn ids in the same stream, support multiple server ids in the same transaction, ban triggers in multi-statement transaction? Can we attribute local changes to the same server id? We don't have to replicate them back - this is a gray zone and we can do it in any way we want. -- Konstantin Osipov, Moscow, Russia, +7 903 626 22 32 http://tarantool.io - www.twitter.com/kostja_osipov