From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-f196.google.com (mail-lj1-f196.google.com [209.85.208.196]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 7EEFD46970E for ; Fri, 31 Jan 2020 22:44:50 +0300 (MSK) Received: by mail-lj1-f196.google.com with SMTP id x7so8347287ljc.1 for ; Fri, 31 Jan 2020 11:44:50 -0800 (PST) Date: Fri, 31 Jan 2020 22:44:48 +0300 From: Konstantin Osipov Message-ID: <20200131194448.GA17326@atlas> References: <20200124151706.18482-1-gorcunov@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200124151706.18482-1-gorcunov@gmail.com> Subject: Re: [Tarantool-patches] [PATCH] box/txn: do not zap fiber txn pointer before txn_write_to_wal completes List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Cyrill Gorcunov Cc: tml * Cyrill Gorcunov [20/01/24 18:18]: > The txn_write_to_wal operates with txn by own: on success it calls > txn_entry_done_cb which completes transaction, on error it calls > txn_rollback which expects the transaction we're rolling back is > the one the fiber carries in storage. > > | txn_write > | fiber_set_txn(fiber(), NULL); // zap fiber's storage.txn > | txn_write_to_wal(txn); > | journal_entry_new(..., txn_entry_done_cb, ...) > | if (req == NULL) > | txn_rollback(txn); > | assert(txn == in_txn()); // in_txn()=nil, triggers Wile I agree this call chain is problematic... > index bedb57449..060d91536 100644 > --- a/src/box/txn.c > +++ b/src/box/txn.c > @@ -583,7 +583,6 @@ txn_write(struct txn *txn) > fiber_set_txn(fiber(), NULL); > return 0; > } > - fiber_set_txn(fiber(), NULL); > return txn_write_to_wal(txn); I believe Georgy added this for a reason - since the current fiber is no longer locked until the transaction is resumed, it should be removed from the fiber key (this change AFAIU comes from parallel applier patch). I suggest you move this statement inside txn_write_to_wal(). I can't find a good place for it yet though. -- Konstantin Osipov, Moscow, Russia