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 6AE0B6F3C7; Fri, 26 Mar 2021 15:35:47 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 6AE0B6F3C7 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1616762147; bh=8hIiSr+DFPxYo5F5FdrUEegsFXcqGkqthyi9XkiYo5I=; 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=tT3ypn5SGHMuhS7Ozsc+9HwAAiCSISt2jYMgXR7w4z7kK8d5euyIlaOSI3Pp/DtBx QKeb6kEMGFQVGiCFT3/dwiELCM16rOzluwtcHfdCd2l3UzygQwgz/JC6frW9S7FlbJ 38FCg02HBrsxzuJ/2NC884kYdaIJs+yh60mSkm6w= Received: from mail-lf1-f53.google.com (mail-lf1-f53.google.com [209.85.167.53]) (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 ED5666F3C7 for ; Fri, 26 Mar 2021 15:35:45 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org ED5666F3C7 Received: by mail-lf1-f53.google.com with SMTP id 75so7459347lfa.2 for ; Fri, 26 Mar 2021 05:35:45 -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=aJIiGmyhN1qvmDlAk9B5HqvWY8ONk+JrgaUMg7321Fk=; b=kyom1OW1552uSarXUxueRAcBtveNb1MytMk9VAiPNOrla/TOIqu5VC5BZCH+ellbbH /VbuJaxMmQN/eLlhOJuURW4U+D/uzhbt/u7ClqksAmuWaP2QfIj0iQ+GSFrdjq3p/LL4 NHMSQKiFHuE+4zlJiJzSWzUvuH4GR+B80ywZrcmhjI/ok5GGHg0XJK3oUDTWJ0vFFm2i aXvZj04oFO/sgyX7q5xtkG3rkGarPmR+RLgR6MjBPUV0JSfmv5N2Bhqrt24MwbA57dPh 86yb9Z1O7R5RYz0A19va2NWl2xxW3QXtYbnD1yoaG7b7D7N4QEnFLUZsTGLBVQhwM/O+ YNQQ== X-Gm-Message-State: AOAM532FlE0Q/kkL18e22xtQp0xktT9zpma/ioqktfznPUli8LQpCbyR cpfyagPXX65aXwQpHAhlRVhXyoxfnuYH9A== X-Google-Smtp-Source: ABdhPJz3M+IbBouoHZqdIP2xJhHOHvUVkS3YqIn5T2hZHAd9rHkzXu/pdzqG/O0F2ZnfHr3N3Vt31w== X-Received: by 2002:a05:6512:338a:: with SMTP id h10mr8318821lfg.277.1616762144285; Fri, 26 Mar 2021 05:35:44 -0700 (PDT) Received: from grain.localdomain ([5.18.171.94]) by smtp.gmail.com with ESMTPSA id s17sm1115488lji.101.2021.03.26.05.35.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 26 Mar 2021 05:35:43 -0700 (PDT) Received: by grain.localdomain (Postfix, from userid 1000) id 55B5B5601CB; Fri, 26 Mar 2021 15:35:42 +0300 (MSK) Date: Fri, 26 Mar 2021 15:35:42 +0300 To: Serge Petrenko Cc: v.shpilevoy@tarantool.org, tarantool-patches@dev.tarantool.org Message-ID: References: <31d242da3f691029c6fc670c902290a77fe36ae1.1616588119.git.sergepetrenko@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <31d242da3f691029c6fc670c902290a77fe36ae1.1616588119.git.sergepetrenko@tarantool.org> User-Agent: Mutt/2.0.5 (2021-01-21) Subject: Re: [Tarantool-patches] [PATCH v2 2/7] applier: extract tx boundary checks from applier_read_tx into a separate routine 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 Wed, Mar 24, 2021 at 03:24:12PM +0300, Serge Petrenko wrote: > Introduce a new routine, set_next_tx_row(), which checks tx boundary > violation and appends the new row to the current tx in case everything > is ok. > > set_next_tx_row() is extracted from applier_read_tx() because it's a > common part of transaction assembly both for recovery and applier. > > The only difference for recovery will be that the routine which's > responsible for tx assembly won't read rows. It'll be a callback ran on > each new row being read from WAL. > > Prerequisite #5874 > Part-of #5566 > --- > src/box/applier.cc | 117 +++++++++++++++++++++++---------------------- > 1 file changed, 60 insertions(+), 57 deletions(-) > > diff --git a/src/box/applier.cc b/src/box/applier.cc > index 326cf18d2..65afa5e98 100644 > --- a/src/box/applier.cc > +++ b/src/box/applier.cc > @@ -657,6 +657,64 @@ applier_read_tx_row(struct applier *applier) > return tx_row; > } > > +static inline int64_t > +set_next_tx_row(struct stailq *rows, struct applier_tx_row *tx_row, int64_t tsn) Serge, why it is "inline"? I propose to not use inline until really needed. The compiler may ignore inline word, same time if function is small the compiler may inline it as a part of optimisation stage. Not a big deal, feel free to ignore, but I see "inline" is used too much all over the code :( https://www.kernel.org/doc/html/v4.10/process/coding-style.html#the-inline-disease