From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <v.shpilevoy@tarantool.org>
Received: from smtp3.mail.ru (smtp3.mail.ru [94.100.179.58])
 (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 1B3A843D678
 for <tarantool-patches@dev.tarantool.org>;
 Tue, 22 Oct 2019 02:00:35 +0300 (MSK)
From: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
Reply-To: tarantool-patches@freelists.org
References: <cover.1568798455.git.georgy@tarantool.org>
 <0d9ae1e9b32cb8334bf6007de4cb62ce62f87fcb.1568798455.git.georgy@tarantool.org>
 <0db07768-c555-a3f6-12d0-a33a267deaf7@tarantool.org>
 <2613444.GBVTE10AvH@home.lan>
 <84edf0e4-a878-64be-d2f3-694cc672ec9a@tarantool.org>
Message-ID: <9e67198b-c370-353b-c1f4-cef1dc37ecb1@tarantool.org>
Date: Tue, 22 Oct 2019 01:05:49 +0200
MIME-Version: 1.0
In-Reply-To: <84edf0e4-a878-64be-d2f3-694cc672ec9a@tarantool.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Subject: Re: [Tarantool-patches] [tarantool-patches] Re: [PATCH v2 4/4]
 replication: use wal memory buffer to fetch rows
List-Id: Tarantool development <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: Georgy Kirichenko <georgy@tarantool.org>
Cc: tarantool-patches@freelists.org, tarantool-patches@dev.tarantool.org



On 23/09/2019 23:51, Vladislav Shpilevoy wrote:
> Thanks for the answers.
> 
>>>> +			struct vclock *send_vclock;
>>>> +			if (relay->version_id < version_id(1, 7, 4))
>>>> +				send_vclock = &relay->r->vclock;
>>>
>>> 3. I know, this is old code existed before your patch, and it will
>>> be dropped, but why do you send relay->r->vclock and don't decode it
>>> anywhere? Above you decoded a received vclock into relay->recv_vclock.
>>> relay->r->vclock is not updated, and nonetheless you send it.
>> Before 1.7.4 we used recovery vclock as replica vclock. So recovery does the 
>> work.
> 
> It *did* the work, but now it doesn't. Recovery vclock was being
> updated in relay_process_wal_event(). Now you relay directly
> from memory, and recovery vclock is not changed until you fall
> to disk. Moreover, looks like recovery object does not exist until
> you fall to disk. It means, that to 1.7.4 you would either crash or
> send the same vclock until a next fall to disk, wouldn't you?
> 

Any news here?