From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from [87.239.111.99] (localhost [127.0.0.1]) by dev.tarantool.org (Postfix) with ESMTP id 1D9147030D; Mon, 13 Sep 2021 01:25:42 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 1D9147030D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1631485542; bh=r8i4nk0MIttzQ56QkerjAv58YI4fsB5hExJFR/HTSLE=; h=Date:To:References:In-Reply-To:Subject:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=oEZMae/N4MZdxqi2xb8744TrZPLDhSayfOeweMCJRv7rEG8Y9/V0sH/5DiETD2CEs nE10/nc0kOibe6vzSPBTdbMslsDFmvCzHVRUIcgppmtZaXUJk1NpX1Z3Lh4U3w+I1H N84jXqIO1dfzc0ydoeMLQBKgsaHUdfi1PK1MGb5E= Received: from mail-lf1-f51.google.com (mail-lf1-f51.google.com [209.85.167.51]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 05D577030D for ; Mon, 13 Sep 2021 01:25:41 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 05D577030D Received: by mail-lf1-f51.google.com with SMTP id s10so16861239lfr.11 for ; Sun, 12 Sep 2021 15:25:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=/SIlMmvh0uuT0kKQIC5lNRY3Z8QZsGkMqKxBlQfZiHM=; b=HLj/slTAMUPOZw+kNMDnkzrzHuCe6sOWMWLErBCGi20X8K0/QueVcHQ3uhp7DdRYHg rHlvCKLZazG01esZq12QpE/91Rh/WycImXB8jibEaePhY0/e6KXEjI6bQd/pYb4K7w/F thmzn1YW10hO7gStpbdTiroDt+vTF1nfdcYOCcoix/Sf54mYa2aNPz9Ix/fmvD7WpS2m YRxTZ4E3BKtqt55s+/JWqHqLLXrEQasvXbaxQiiZN9oIQJPv1QpYpjA00p4PPYzw11Le lq17sfGpWNy4dbiujhs0OYNXUO+LtwdBu5CX/QQ8RNfxVFWLeWoP5OSAWoQL65sjfhJh d1EA== X-Gm-Message-State: AOAM531kJe2YRQxHWyu/3QELzYHi39LIVpVJEJL6Kz+eQjSDwmJe3HTx R+xxmATgRFzsJ5MFOegNGPIjiB+WHiA= X-Google-Smtp-Source: ABdhPJyO8cPswRxSOoCx8NLk1oCVU7i3h5hTzaj7P0MjU6DpLc+tOfaL2Awti9GO9bS1X8m4x8HYHA== X-Received: by 2002:a05:6512:3084:: with SMTP id z4mr6815216lfd.330.1631485540028; Sun, 12 Sep 2021 15:25:40 -0700 (PDT) Received: from grain.localdomain ([5.18.253.97]) by smtp.gmail.com with ESMTPSA id k16sm630661lfj.231.2021.09.12.15.25.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 12 Sep 2021 15:25:39 -0700 (PDT) Received: by grain.localdomain (Postfix, from userid 1000) id BBCB25A001E; Mon, 13 Sep 2021 01:25:38 +0300 (MSK) Date: Mon, 13 Sep 2021 01:25:38 +0300 To: Vladislav Shpilevoy Message-ID: References: <20210910152910.607398-1-gorcunov@gmail.com> <20210910152910.607398-3-gorcunov@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/2.0.7 (2021-05-04) Subject: Re: [Tarantool-patches] [PATCH v14 2/6] qsync: update confirmed lsn on initial promote request X-BeenThere: tarantool-patches@dev.tarantool.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Cyrill Gorcunov via Tarantool-patches Reply-To: Cyrill Gorcunov Cc: tml Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" On Sun, Sep 12, 2021 at 05:44:04PM +0200, Vladislav Shpilevoy wrote: > Thanks for the patch! > > On 10.09.2021 17:29, Cyrill Gorcunov wrote: > > When promote request is handled we drop last confirmed > > lsn to zero because its value make sense for sync queue > > owner only. Still the case where we become queue owner > > for the first time is special - we need to fetch the > > obtained lsn from the request and remember it so we > > will be able to filter any next malformed requests > > with wrong lsn numbers (see queue filtering procedure > > in next patch). > > I don't understand anything. Why isn't it needed always? And > how exactly will it help to filter stuff? This problem is revealed when run of ./test-run replication/gh-6034-qsync-limbo-ownership.test.lua with filteration turned on. The confirmed_lsn make sence in bound with limbo owner as far as I understand. And in test we have two nodes "default" and "replica". Initially default gets up, filled with some data into sync space and then we start up a replica node. The replica get subscribed and then we call box.promote() on it, since replica itself has not been writting anything its confirmed_lsn = 0, which we send back to the "default" inside promote request body. And it get rejected because "default" has non-zero confirmed_lsn. I've been talking to Serge a lot about this problem and if I'm not missing somthing obvious updating this filed on first promote arrival is mostly correct way to handle the issue. I presume we should get a meeting and talk again. Or maybe better via email. Serge could you please write the details here?