From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp17.mail.ru (smtp17.mail.ru [94.100.176.154]) (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 CFE804696C3 for ; Tue, 7 Apr 2020 15:22:50 +0300 (MSK) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Serge Petrenko In-Reply-To: <719eb559-bb1e-389d-79f4-02c48bfa5d19@tarantool.org> Date: Tue, 7 Apr 2020 15:22:49 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <878aa23b480e70d95ce0fba5a0572aa58e8c4e6e.1585565637.git.sergepetrenko@tarantool.org> <719eb559-bb1e-389d-79f4-02c48bfa5d19@tarantool.org> 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: Vladislav Shpilevoy Cc: tarantool-patches@dev.tarantool.org Hi! Thanks for the review! > 4 =D0=B0=D0=BF=D1=80. 2020 =D0=B3., =D0=B2 23:51, Vladislav Shpilevoy = =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0= =B0): >=20 > Thanks for the patch! >=20 > Was it considered to ignore 0 component on receiver's > side rather than on sender's? >=20 > I see this: >=20 >> This is needed for backward compatibility with old instances, = which >> don't ignore 0th vclock component coming from a remote instance by >> default. >=20 > But can anon replicas connect to old versions? Anon replicas can be promoted to normal ones, and then connect to old versions, while still having a non-zero vclock[0]. >=20 > I am not saying that it would be better, but I don't > see why technically not. >=20 > 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. >>=20 >> 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. >>=20 >> 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(-) >>=20 >> 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); >=20 > 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. Okay, will do. >=20 > Probably even the original xrow_encode_vclock can appear to be > not needed anywhere. -- Serge Petrenko sergepetrenko@tarantool.org