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 DA9DB6EC55; Mon, 12 Jul 2021 18:48:13 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org DA9DB6EC55 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1626104893; bh=88UGZU/FRfrhS20rIbQRqRw4LluTSEECpG8/DVwJBis=; 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=StzZ8Bfcj0NbD0SbzCgccPQWgdLhD7bYEOfp6a9fhm0jubUNDdJg04GYpOgDjSR16 buwJBO59s8idGzEiL/+IewIJAzqNaZFqRHPPR2Y3fIuEH6jHJb6EVHJPR8dB1WHkfl aw3I1erOWZM4xFig8dbJuXo+0Twbj+yyWXeZ3VIQ= Received: from mail-lf1-f49.google.com (mail-lf1-f49.google.com [209.85.167.49]) (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 09DF76EC55 for ; Mon, 12 Jul 2021 18:48:13 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 09DF76EC55 Received: by mail-lf1-f49.google.com with SMTP id f30so44216622lfj.1 for ; Mon, 12 Jul 2021 08:48:12 -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=mEuoIGSfcjexnO8CRkgl3v7CN9L9Ozkw2Ii2hTWDjog=; b=h1ejjq6j44+QZ1TMAa2hDJbmwAaP+UnVhMhdSCPycJxwJOYawfuIWd9igK22OnruLh XS7RIHysZ9zguMtkWsm32J1bh9cqxgXuIVhqV5mkCPcRHYqJt4ikR31dz0I6WVYPPqGB OW60urNroU5tJvN5vXDST1HsXr/TLkNu8R2nsDf8+7w+4EjFxju35CrfvLdwnTum8FKs zCkEaGxIcfVOReuwBvJ6hNjbM9ypJsvSduioAHSxFn+7r55s0/jMYsvRIbPH6nx8vKCG pYWWm38sBuzHy4eXKBam9idYDEhgsymUFJSz+G8Q70gGXQzZz2o3+ni9hxEVK+QkbjNY ZRyQ== X-Gm-Message-State: AOAM531yaKdDkS5mg4QKzbGguqAIrmIwh4IHvRJOND1S8k85MKIfDaOZ kVuwnDHpmNXp/37AbbYRjGQ3uCNgOvPYSQ== X-Google-Smtp-Source: ABdhPJx7jNBtQnDX8ka6iAbgatToOH8eqMEuFwmMSsLm2gk/E45LwixuBfmKadKZfraXYQdu1DwG5A== X-Received: by 2002:ac2:58e8:: with SMTP id v8mr15122511lfo.14.1626104891578; Mon, 12 Jul 2021 08:48:11 -0700 (PDT) Received: from grain.localdomain ([5.18.199.94]) by smtp.gmail.com with ESMTPSA id h11sm731253lfc.177.2021.07.12.08.48.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Jul 2021 08:48:10 -0700 (PDT) Received: by grain.localdomain (Postfix, from userid 1000) id D48355A001E; Mon, 12 Jul 2021 18:48:08 +0300 (MSK) Date: Mon, 12 Jul 2021 18:48:08 +0300 To: Serge Petrenko , Vladislav Shpilevoy Cc: 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: 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" Guys, there are some moments even in current code structure which looks somehow strange so I would like to discuss them. Lets consider the following case: one replic sends us a promote request (assume we're sitting in term 2 and max term is 2). applier 1 --------- applier_apply_tx (promote term = 3 current max term = 2) applier_synchro_filter_tx apply_synchro_row journal_write (sleeping) at this moment another applier comes in with obsolete data and term 2 applier 2 --------- applier_apply_tx (term 2) applier_synchro_filter_tx txn_limbo_is_replica_outdated -> false journal_write (sleep) applier 1 --------- journal wakes up apply_synchro_row_cb set max term to 3 return to applier read and applier 2 could finish its write and wake up too at this moment the data from applier 2 is actually queued for write as valid but we just wrote the term 3, so if we would had been updating terms map earlier (before jornal write) the data from applier 2 should be NOPified. I think there is some problem because due to journal write lag the data is not as it could be if terms map updated early. Serge, Vlad, am I right? Which consequences can be here? IOW, should not we track terms earlier even without my filter series?