From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <vdavydov.dev@gmail.com>
Date: Tue, 27 Nov 2018 12:57:09 +0300
From: Vladimir Davydov <vdavydov.dev@gmail.com>
Subject: Re: [PATCH 4/6] box: use replicaset.vclock in replica join/subscribe
Message-ID: <20181127095709.4bwqvi346k5qbuqv@esperanza>
References: <cover.1543152574.git.vdavydov.dev@gmail.com>
 <2ab0d1a4bf8a5050ad4ea764b5cab41fd1d5968d.1543152574.git.vdavydov.dev@gmail.com>
 <20181126175458.GE7839@chai>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20181126175458.GE7839@chai>
To: Konstantin Osipov <kostja.osipov@gmail.com>
Cc: tarantool-patches@freelists.org
List-ID: <tarantool-patches.dev.tarantool.org>

On Mon, Nov 26, 2018 at 08:54:58PM +0300, Konstantin Osipov wrote:
> * Vladimir Davydov <vdavydov.dev@gmail.com> [18/11/26 10:27]:
> > Again, this is something that was introduced by commit f2bccc18485d
> > ("Use WAL vclock instead of TX vclock in most places") without any
> > justification.
> > 
> > TX has its own copy of the current vclock - there's absolutely no need
> > to inquire it from the WAL thread. Actually, we already use TX local
> > vclock in box_process_vote(). No reason to treat join/subscribe any
> > different. Moreover, it's even harmful - there may be a gap at the end
> > of a WAL file, in which case WAL vclock will be slightly ahead of TX
> > vclock so that should a replica try to subscribe it would never finish
> > syncing, see #3830.
> 
> OK to push.

Pushed to 2.1