From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gorcunov@gmail.com>
Received: from mail-lf1-f68.google.com (mail-lf1-f68.google.com
 [209.85.167.68])
 (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 CDA774696C3
 for <tarantool-patches@dev.tarantool.org>;
 Thu, 23 Apr 2020 12:54:15 +0300 (MSK)
Received: by mail-lf1-f68.google.com with SMTP id r17so4260762lff.2
 for <tarantool-patches@dev.tarantool.org>;
 Thu, 23 Apr 2020 02:54:15 -0700 (PDT)
Date: Thu, 23 Apr 2020 12:54:13 +0300
From: Cyrill Gorcunov <gorcunov@gmail.com>
Message-ID: <20200423095413.GE3072@uranus>
References: <20200422182810.79257-1-sergepetrenko@tarantool.org>
 <20200423094112.GD3072@uranus>
 <28487782-9C98-432A-95E1-A3583C96A564@tarantool.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <28487782-9C98-432A-95E1-A3583C96A564@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, Vladislav Shpilevoy <v.shpilevoy@tarantool.org>

On Thu, Apr 23, 2020 at 12:53:30PM +0300, Serge Petrenko wrote:
> 
> > 23 апр. 2020 г., в 12:41, Cyrill Gorcunov <gorcunov@gmail.com> написал(а):
> > 
> > On Wed, Apr 22, 2020 at 09:28:10PM +0300, 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
Reviewed-by: Cyrill Gorcunov <gorcunov@gmail.com>

Thanks!