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 15E246FC85; Tue, 14 Sep 2021 22:41:21 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 15E246FC85 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1631648481; bh=o2Hvmw3ulNswPHSDti/ZXQtBZ+iqJu+0r7wKsEA0dMo=; 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=Jo/ZYcBIpCEQ4jKUiWjN9lAuBpM63LA+EdbH1SrJOQH7D6FFv6I77KQPKaVdg6dsJ 6G7wnCx8Xr/Un7dLXIa0DX1K2rexXui/UEJ8KLj8BBaiWrVnXqO6kuSdb892mcWoFA cVZLSzr8afDbrBeVxCft1ri3SX2YLQrlYM/PdjLc= Received: from mail-lj1-f180.google.com (mail-lj1-f180.google.com [209.85.208.180]) (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 DF3206FC85 for ; Tue, 14 Sep 2021 22:41:19 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org DF3206FC85 Received: by mail-lj1-f180.google.com with SMTP id f2so806753ljn.1 for ; Tue, 14 Sep 2021 12:41:19 -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=JMTTvQZ14jWLIdW5nPC/8XpOlNhL6yiMjbS/LVHtOtg=; b=M2LDZPgAnpQO7kb1L5X4DkBibwshof/aMb/yzET9utayX/Y3QSDzYlZ0FTiE1uxuux mMVfEGEzwQbOzdrdY4iIOt+I5uP3KUNJZNhHjUGFgdHxIWIsGlwhOzk5JxoWD+4hgqB+ VW0Zq6femkbx9JGYmz3/WeUVUu6dc6EFUdnvKg+XBjdwi78JSDln/Ts82LnK9PdmiUYQ kOArm3kO8NLNrU8oEOFqFHaHK1osmWxdWCBzamS/NTNLm51gS+aL3gVarkgxkrsFp5qW jmKmlpa4ckEMxjM/Igx9+C79G/NqqhrM4y39ahv1GAnsGkhrm9a7YqVnN7avSlFBAHfv GrGw== X-Gm-Message-State: AOAM532tvvgvCj0DbagYdvS5SgzKJAuYuDNtJVGi9EByrjt5/BLbmBHB b40l6mG/kgULzkHlz2kExc3lockXYyA= X-Google-Smtp-Source: ABdhPJx/DSR24mN0EFr6hRjfdvaDXSZ0YimbjkwZkmNLtkt7fC8e2HUhoTiLMRpqn4MkepYGu3kQ5A== X-Received: by 2002:a2e:b042:: with SMTP id d2mr17086631ljl.279.1631648478815; Tue, 14 Sep 2021 12:41:18 -0700 (PDT) Received: from grain.localdomain ([5.18.253.97]) by smtp.gmail.com with ESMTPSA id t8sm1387548ljg.103.2021.09.14.12.41.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Sep 2021 12:41:17 -0700 (PDT) Received: by grain.localdomain (Postfix, from userid 1000) id A59D05A001E; Tue, 14 Sep 2021 22:41:16 +0300 (MSK) Date: Tue, 14 Sep 2021 22:41:16 +0300 To: Vladislav Shpilevoy Message-ID: References: <20210910152910.607398-1-gorcunov@gmail.com> <20210910152910.607398-6-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 5/6] qsync: filter incoming synchro requests 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:15PM +0200, Vladislav Shpilevoy wrote: > > @@ -1686,15 +1685,17 @@ box_issue_promote(uint32_t prev_leader_id, int64_t promote_lsn) > > .lsn = promote_lsn, > > .term = raft->term, > > }; > > - txn_limbo_process(&txn_limbo, &req); > > + if (txn_limbo_process(&txn_limbo, &req) != 0) > > + return -1; > > 5. There was already done txn_limbo_write_promote() above. If you > bail now, you have an inconsistent state - in WAL the promote is > written, in the limbo it is not applied. What will happen on recovery? > > It seems you need to lock box_promote(), box_promote_qsync(), > and box_demote(). Otherwise you have the exact same problem with > local promotions vs coming from the applier as the one you tried > to fix for applier vs applier. That's a good point, but as you pointed in previous reviews we should try to remove locking from api (which i did in new yet not sent patches) thus we need some kind of a safe filter which would take a lock, filter request, and release the lock then... As to me our try to hide locking was a mistake in first place, locks I proposed simply serialize access to terms they are underlated to begin/commit/rollback semantics. Actually for now I'm not sure which approach would fit your architecture ideas. Maybe some txn_limbo_filter() helper exposed?