From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtpng3.m.smailru.net (smtpng3.m.smailru.net [94.100.177.149]) (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 58C7F4696C5 for ; Sat, 4 Apr 2020 23:51:53 +0300 (MSK) References: <878aa23b480e70d95ce0fba5a0572aa58e8c4e6e.1585565637.git.sergepetrenko@tarantool.org> From: Vladislav Shpilevoy Message-ID: <719eb559-bb1e-389d-79f4-02c48bfa5d19@tarantool.org> Date: Sat, 4 Apr 2020 22:51:51 +0200 MIME-Version: 1.0 In-Reply-To: <878aa23b480e70d95ce0fba5a0572aa58e8c4e6e.1585565637.git.sergepetrenko@tarantool.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [Tarantool-patches] [PATCH v5 2/4] replication: hide 0-th vclock components in replication responses List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Serge Petrenko , kostja.osipov@gmail.com Cc: tarantool-patches@dev.tarantool.org Thanks for the patch! Was it considered to ignore 0 component on receiver's side rather than on sender's? I see this: > This is needed for backward compatibility with old instances, which > don't ignore 0th vclock component coming from a remote instance by > default. But can anon replicas connect to old versions? I am not saying that it would be better, but I don't see why technically not. On 30/03/2020 13:04, Serge Petrenko wrote: > If an anonymous replica is promoted to a normal one and becomes > replication master later, its vclock contains a non-empty zero > component, tracking local changes on this replica from the time when it > had been anonymous. No need to pollute joining instance's vclock with > our non-empty 0 component. > When an anonymous replica reports its status to a remote instance it > should also hide its 0-th vclock component. > > This is needed for backward compatibility with old instances, which > don't ignore 0th vclock component coming from a remote instance by > default. > Also make sure that new instances ignore 0th vclock component. > > Follow-up #3186 > Prerequisite #4114 > --- > src/box/applier.cc | 4 +++- > src/box/box.cc | 12 ++++++++---- > src/box/relay.cc | 6 ++++-- > test/replication/anon.result | 5 +++++ > test/replication/anon.test.lua | 2 ++ > 5 files changed, 22 insertions(+), 7 deletions(-) > > diff --git a/src/box/applier.cc b/src/box/applier.cc > index 47a26c366..f5f67b6a9 100644 > --- a/src/box/applier.cc > +++ b/src/box/applier.cc > @@ -173,7 +173,9 @@ applier_writer_f(va_list ap) > continue; > try { > struct xrow_header xrow; > - xrow_encode_vclock(&xrow, &replicaset.vclock); > + struct vclock vclock; > + vclock_copy_ignore0(&vclock, &replicaset.vclock); > + xrow_encode_vclock(&xrow, &vclock); xrow_encode_vclock without 0 component is needed 4 times. With 0 it is encoded 2 times. Maybe better add a function xrow_encode_vclock_ignore0 or like that. Because copy_ignore0 is copying of ~290 bytes. This is several cache lines. Probably even the original xrow_encode_vclock can appear to be not needed anywhere.