From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-f195.google.com (mail-lj1-f195.google.com [209.85.208.195]) (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 8C40C469719 for ; Mon, 14 Sep 2020 11:12:05 +0300 (MSK) Received: by mail-lj1-f195.google.com with SMTP id n25so17829208ljj.4 for ; Mon, 14 Sep 2020 01:12:05 -0700 (PDT) Date: Mon, 14 Sep 2020 11:12:02 +0300 From: Cyrill Gorcunov Message-ID: <20200914081202.GD269870@grain> References: <5a6c33ec7bfffd3d0dd201a1b38cc5205f0f0ea4.1600025872.git.v.shpilevoy@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5a6c33ec7bfffd3d0dd201a1b38cc5205f0f0ea4.1600025872.git.v.shpilevoy@tarantool.org> Subject: Re: [Tarantool-patches] [PATCH v2 1/1] memtx: force async snapshot transactions List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Vladislav Shpilevoy Cc: tarantool-patches@dev.tarantool.org On Sun, Sep 13, 2020 at 09:39:26PM +0200, Vladislav Shpilevoy wrote: > Snapshot rows contain not real LSNs. Instead their LSNs are > signatures, ordinal numbers. Rows in the snap have LSNs from 1 to > the number of rows. This is because LSNs are not stored with every > tuple in the storages, and there is no way to store real LSNs in > the snapshot. > > These artificial LSNs broke the synchronous replication limbo. > After snap recovery is done, limbo vclock was broken - it > contained numbers not related to reality, and affected by rows > from local spaces. > > Also the recovery could stuck because ACKs in the limbo stopped > working after a first row - the vclock was set to the final > signature right away. > > This patch makes all snapshot recovered rows async. Because they > are confirmed by definition. So now the limbo is not involved into > the snapshot recovery. > > Closes #5298 Reviewed-by: Cyrill Gorcunov