From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <kyukhin@tarantool.org>
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 dev.tarantool.org (Postfix) with ESMTPS id 3D64E4696C3
 for <tarantool-patches@dev.tarantool.org>;
 Mon, 27 Apr 2020 13:22:07 +0300 (MSK)
Date: Mon, 27 Apr 2020 13:22:06 +0300
From: Kirill Yukhin <kyukhin@tarantool.org>
Message-ID: <20200427102206.4gbk5pimw3gfg2nj@tarantool.org>
References: <20200422182810.79257-1-sergepetrenko@tarantool.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20200422182810.79257-1-sergepetrenko@tarantool.org>
Subject: Re: [Tarantool-patches] [PATCH] applier: follow vclock to the last
 tx row
List-Id: Tarantool development patches <tarantool-patches.dev.tarantool.org>
List-Unsubscribe: <https://lists.tarantool.org/mailman/options/tarantool-patches>, 
 <mailto:tarantool-patches-request@dev.tarantool.org?subject=unsubscribe>
List-Archive: <https://lists.tarantool.org/pipermail/tarantool-patches/>
List-Post: <mailto:tarantool-patches@dev.tarantool.org>
List-Help: <mailto:tarantool-patches-request@dev.tarantool.org?subject=help>
List-Subscribe: <https://lists.tarantool.org/mailman/listinfo/tarantool-patches>, 
 <mailto:tarantool-patches-request@dev.tarantool.org?subject=subscribe>
To: Serge Petrenko <sergepetrenko@tarantool.org>
Cc: tarantool-patches@dev.tarantool.org, v.shpilevoy@tarantool.org

Hello,

On 22 апр 21:28, Serge Petrenko wrote:
> Since the introduction of transaction boundaries in replication
> protocol, appliers follow replicaset.applier.vclock to the lsn of the
> first row in an arrived batch. This is enough and doesn't lead to errors
> when replicating from other instances, respecting transaction boundaries
> (instances with version 2.1.2 and up). However, if there's a 1.10
> instance in 2.1.2+ cluster, it sends every single tx row as a separate
> transaction, breaking the comparison with replicaset.applier.vclock and
> making the applier apply part of the changes, it has already applied
> when processing a full transaction coming from another 2.x instance.
> Such behaviour leads to ER_TUPLE_FOUND errors in the scenario described
> above.
> In order to guard from such cases, follow replicaset.applier.vclock to
> the lsn of the last row in tx.
> 
> Closes #4924
> ---
> https://github.com/tarantool/tarantool/issues/4924
> https://github.com/tarantool/tarantool/tree/sp/gh-4924-applier-duplicate-key

I've checked your patch into 2.3 and master.

--
Regards, Kirill Yukhin