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 00B4C469719 for ; Wed, 19 Feb 2020 11:52:56 +0300 (MSK) Received: by mail-lj1-f195.google.com with SMTP id a13so26176094ljm.10 for ; Wed, 19 Feb 2020 00:52:56 -0800 (PST) Date: Wed, 19 Feb 2020 11:52:54 +0300 From: Konstantin Osipov Message-ID: <20200219085254.GB6538@atlas> References: <257cb279bd1b62ef6ff98aa4fa7226ba1bf3b2d0.1582046958.git.sergepetrenko@tarantool.org> <20200218190324.GB20569@atlas> <93920A98-9B17-43AB-86C2-494161FC032B@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <93920A98-9B17-43AB-86C2-494161FC032B@tarantool.org> Subject: Re: [Tarantool-patches] [PATCH v3 2/4] recovery: allow to ignore rows coming from a certain instance List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Serge Petrenko Cc: tarantool-patches@dev.tarantool.org, Vladislav Shpilevoy * Serge Petrenko [20/02/19 11:45]: > > This is a strange way to mute rows from self. Why not set vclock > > component to infinity as I suggested multiple times? Why not > > respond to me with objection if my suggestion can not be done? > > I responded with a patch, so now we can discuss both your and my suggestions. No, we can't. You responded with a patch for your suggestion, but not for mine. So we compare apples and oranges here. Just like with Ilya's patch, which only half way captured my suggestion in his "alternatives". In the end I'm not even sure you got it right. > If I understood you correctly, you suggested to set replica self lsn to infinity > (on master side), so that recovery on masters side would skip replicas rows. > > I tried your approach and initialized recovery with vclock[replica_id] = INT64_MAX. > This does allow you to skip replica’s rows, but this breaks vclock signature, which will > overflow immediately. vclock signatures are used to order gc consumers, gc > consumer corresponding to a replica gets its vclock from relay recovery. > Ok, you could suggest to reset vclock[replica_id] to some meaningful value, but where > do you get this value from? You cannot do gc message vclock[replica_id] = > replica ack vclock[replica_id], because replica may have some rows you still > don’t have. Then replica ack vclock signature may get too big and you will delete > other logs containing your changes. > You also cannot set gc vclock[replica_id] to 0, because it will hold logs, not needed by > replica for too long. Please send a patch and we'll be able to discuss where it went wrong for you. -- Konstantin Osipov, Moscow, Russia