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 3D7D226D68 for ; Mon, 11 Mar 2019 06:54:11 -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 aWKDzUzyJ5J2 for ; Mon, 11 Mar 2019 06:54:11 -0400 (EDT) Received: from smtp50.i.mail.ru (smtp50.i.mail.ru [94.100.177.110]) (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 845C024336 for ; Mon, 11 Mar 2019 06:54:10 -0400 (EDT) From: Georgy Kirichenko Subject: [tarantool-patches] Re: [PATCH v3 1/2] Write rows without a lsn to the transaction tail Date: Mon, 11 Mar 2019 13:54:03 +0300 Message-ID: <1611415.TB3NjmJXjb@localhost> In-Reply-To: <20190311095926.GA9866@chai> References: <48e024c9ada966ce68447a7cf24c201b1ebaf27b.1552248901.git.georgy@tarantool.org> <20190311095926.GA9866@chai> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2006528.8YemcgzLOE"; micalg="pgp-sha256"; protocol="application/pgp-signature" 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: Konstantin Osipov --nextPart2006528.8YemcgzLOE Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" On Monday, March 11, 2019 12:59:26 PM MSK Konstantin Osipov wrote: > * 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. If you remember we were agreed that only local spaces are allowed to change in case of replication triggers. > > 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? You pushed me to remove txn_replica_id but it was one of the instruments I planed to use in order to support distributed transactions (with multiple replica ids in the same transaction) in the future. So I would prefer if we just disable changing of non-local spaces during replication. In such case we won't have any issues with reordering. > > Can we attribute local changes to the same server id? It is impossible because of lsn > We don't have to replicate them back - this is a gray zone and we can do it > in any way we want. I'm afraid no because we already have this functionality and it is even covered with tests. So we have to make a high level decision: what is expected behavior. In any case I will be agreed with your decision what we should to do: disable non-local replication changes, change behavior of replication for such changes or start further distributed transaction investigation. --nextPart2006528.8YemcgzLOE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEFZT35EtIMRTDS5hJnoTdFFzh6LUFAlyGPksACgkQnoTdFFzh 6LW2/Qf+NkaKUxWLBAqoYrMipi5ySoG3HI4ESR/RySRx2C1t7r1uwGuhMn2sS3Ag iHyhzuBoL0dAyjYed0qSrE2oOpAsNCB0cZEq1t9iPwx0nmrG5fHnbiek2Ewvzonc pHqDeZqbpemWW0O6TxJ550Xqa9POR/tw8corkQ4xEUhkOl0PVYCxYbVeAB8afCZ5 u+YbzHihmevzoL9F1Sw0FleQTsKNf+0qPZhc8Z/qn1kwTpTIHcz2F7pgkOxw328r a3hoi3hH02mhUX5cMkeqoDnAaaBjjyp9Lpj2+D/i+4oitHezGVwsjoXxNMSGMFQO rHeGma/fIztyKJ8r9+3RR8X4wKO9Og== =AXyh -----END PGP SIGNATURE----- --nextPart2006528.8YemcgzLOE--