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 D29BD6EC55; Mon, 12 Jul 2021 12:43:43 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org D29BD6EC55 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1626083023; bh=DiRx/QKu0rqYGV5EfNmXv4Oqxsk0h6Hui+7Yb9jLzzI=; h=Date:To:Cc:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=FebmQ7vj8OmoWHiB2/6lhSwHd+SGbCsMScd85LcvXedGAXs3uyRVctKLuzMBpv9Dm AfoJ43JYsy109t5fo32K1gjsY4FIqSp/IxpVbPe4p/loNGOOFrfS3IWKtuTE8vnn/p Ib5jJfEW0LAWNyAjTttBay+3eLKYW4G4v5/uEu0g= Received: from mail-lf1-f46.google.com (mail-lf1-f46.google.com [209.85.167.46]) (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 3BD396EC55 for ; Mon, 12 Jul 2021 12:43:42 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 3BD396EC55 Received: by mail-lf1-f46.google.com with SMTP id t17so42205634lfq.0 for ; Mon, 12 Jul 2021 02:43:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=D271r+X4e9IllazK0/zLjnEWSkC/7ELTGcLMugAAiCk=; b=tQbcM+IEIwlF5IwHeUuns8Js9SvcxLFit1Js4asw4NLk6Xe+N7uJvfSWBEI2GvMWSp rOlSAP6W7SSmhj2QISB5g9cH3FKUnW1oJAHaZgwWiekWH6Ubfci2wHAv6gARXHC2jj6O t3wEVNPHV5d7kTbPwRPUYnxP54f8Gx/23UNiQmCh5nIqCdvGnCrk1KyzkQAsZKkxrh19 nJ3DjH2Jj4ro6PMF21dlm7H6QiO37svBlD/hp4ep0LDP3e7xzr1/jTRj+5onzmlWqFuR RR7ylaWAIdflVPW++8bdkdkZmsM4d4uNJQxMQUOEXcTnnKRI8aEsv76jjc37YEZGIiem nptQ== X-Gm-Message-State: AOAM533A4JX5UqrlPMI44LP95H8aF5L8m2KQ6e/Px4imMoKJ1wR64Dkm Np+g7DxDJfdTiB2aAMfpDGBeHbCic0W+PA== X-Google-Smtp-Source: ABdhPJyeBkUj430Qq7HXKw7j9I7KaR6u5HS68Howozb9AXUr7YFg2BVnC0v9paS4B69jDz48b1qHnQ== X-Received: by 2002:ac2:59c1:: with SMTP id x1mr19525161lfn.118.1626083021290; Mon, 12 Jul 2021 02:43:41 -0700 (PDT) Received: from grain.localdomain ([5.18.199.94]) by smtp.gmail.com with ESMTPSA id t72sm1102795lff.172.2021.07.12.02.43.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Jul 2021 02:43:40 -0700 (PDT) Received: by grain.localdomain (Postfix, from userid 1000) id 9AF835A001E; Mon, 12 Jul 2021 12:43:39 +0300 (MSK) Date: Mon, 12 Jul 2021 12:43:39 +0300 To: Serge Petrenko Cc: Vladislav Shpilevoy , tml Message-ID: References: <20210710222803.253251-1-gorcunov@gmail.com> <187d1ae2-99cb-50d4-d5b4-18aa6c5f5546@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <187d1ae2-99cb-50d4-d5b4-18aa6c5f5546@tarantool.org> User-Agent: Mutt/2.0.7 (2021-05-04) Subject: Re: [Tarantool-patches] [PATCH] limbo: introduce request processing hooks 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 Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" On Mon, Jul 12, 2021 at 11:01:29AM +0300, Serge Petrenko wrote: > > Well, I still don't understand what the issue is. We discussed it > > privately already. You simply should not apply anything until WAL > > write is done. And it is not happening now on the master. The > > terms vclock is updated only **after** WAL write. > > > > Why do you need all these new vclocks if you should not apply > > anything before WAL write in the first place? > > If I understand correctly, the issue is that if we filter (and check for > the split brain) after the WAL write, we will end up with a conflicting > PROMOTE in our WAL. Cyrill is trying to avoid this, that's why > he's separating the filter stage. This way the error will reach > the remote peer before any WAL write, and the WAL write won't happen. > > And if we filter before the WAL write, we need the second vclock, which > Cyrill has introduced. > > We may leave confligting PROMOTEs in WAL (first write them and only > then check for conflicts). In this case this whole patch isn't > needed. But I personally don't like such an approach. Exactly. What is more interesting is that each term is involved into maximal term calculation. Imagine we have several appliers running (with early filtering of incoming packets) applier 1 applier 2 --------- --------- applier_apply_tx apply_synchro_row filter - update term - calculate term_max journal_write (sleeping) applier_apply_tx applier_synchro_filter_tx(rows); - the term_max should be already updated so we could NOP data journal_write (will be woken after applier 1 finished its write) Actually I start to think that we might not NOP data until applier's 1 write finished...