From: Vladislav Shpilevoy via Tarantool-patches <tarantool-patches@dev.tarantool.org> To: Cyrill Gorcunov <gorcunov@gmail.com> Cc: tarantool-patches@dev.tarantool.org Subject: Re: [Tarantool-patches] [PATCH 04/13] wal: refactor wal_write_to_disk() Date: Thu, 17 Jun 2021 01:32:52 +0200 [thread overview] Message-ID: <c3ea0f6b-02d8-4bcc-e578-1af7bda0cda3@tarantool.org> (raw) In-Reply-To: <YMmwA//5TKFulb2Z@grain> Hi! Thanks for the review! >>>> @@ -1038,7 +1036,10 @@ wal_write_to_disk(struct cmsg *msg) >>>> { >>>> struct wal_writer *writer = &wal_writer_singleton; >>>> struct wal_msg *wal_msg = (struct wal_msg *) msg; >>>> struct error *error; >>>> + assert(!stailq_empty(&wal_msg->commit)); >>> >>> Hi Vlad, you know I don't understand why we need this assert... >> >> Otherwise in case of, for instance, rotate fail, the rollback won't >> start. > > But the current whole code logic is assuming that if commit chain > is empty then there was no data to write or rollback, iow codeflow > is using list emptiness as a sign of data to procceed. If we really > want to prohibit calling wal_write_to_disk with no entries then > maybe better put panic here? > > The wal_msg->commit entry is accessed later in code anyway via bpu, > which means that if we add > > if (stailq_empty(&wal_msg->commit)) > panic("wal: attempt to update vclock without data"); > > this won't cause perf degradation since after a few lines you gonna be > testing @commit again where bpu entry is already filled and this will > allow us to catch problems on release builds as well. > > Don't get me wrong please I simply don't like assert() with a passion > because it hides problems which might happen on release builds. > > Anyway, just a proposal, if you still prefer calling assert here, ok > let it be. I added the panic: ==================== diff --git a/src/box/wal.c b/src/box/wal.c index 40382e791..cb8b2eac1 100644 --- a/src/box/wal.c +++ b/src/box/wal.c @@ -1039,7 +1039,8 @@ wal_write_to_disk(struct cmsg *msg) struct stailq_entry *last_committed = NULL; struct journal_entry *entry; struct error *error; - assert(!stailq_empty(&wal_msg->commit)); + if (stailq_empty(&wal_msg->commit)) + panic("Attempted to write an empty batch to WAL"); /* * Track all vclock changes made by this batch into
next prev parent reply other threads:[~2021-06-16 23:32 UTC|newest] Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-06-11 21:56 [Tarantool-patches] [PATCH 00/13] Applier rollback reason Vladislav Shpilevoy via Tarantool-patches 2021-06-11 21:56 ` [Tarantool-patches] [PATCH 01/13] error: introduce ER_CASCADE_ROLLBACK Vladislav Shpilevoy via Tarantool-patches 2021-06-11 21:56 ` [Tarantool-patches] [PATCH 10/13] txn: install proper diag errors on txn fail Vladislav Shpilevoy via Tarantool-patches 2021-06-11 21:56 ` [Tarantool-patches] [PATCH 11/13] wal: introduce JOURNAL_ENTRY_ERR_CASCADE Vladislav Shpilevoy via Tarantool-patches 2021-06-11 21:56 ` [Tarantool-patches] [PATCH 12/13] txn: introduce TXN_SIGNATURE_ABORT Vladislav Shpilevoy via Tarantool-patches 2021-06-11 21:56 ` [Tarantool-patches] [PATCH 13/13] txn: stop TXN_SIGNATURE_ABORT override Vladislav Shpilevoy via Tarantool-patches 2021-06-15 13:44 ` Serge Petrenko via Tarantool-patches 2021-06-15 19:34 ` Vladislav Shpilevoy via Tarantool-patches 2021-06-11 21:56 ` [Tarantool-patches] [PATCH 02/13] test: remove replica-applier-rollback.lua Vladislav Shpilevoy via Tarantool-patches 2021-06-11 21:56 ` [Tarantool-patches] [PATCH 03/13] journal: make journal_write() set diag on error Vladislav Shpilevoy via Tarantool-patches 2021-06-11 21:56 ` [Tarantool-patches] [PATCH 04/13] wal: refactor wal_write_to_disk() Vladislav Shpilevoy via Tarantool-patches 2021-06-15 20:46 ` Cyrill Gorcunov via Tarantool-patches 2021-06-16 6:22 ` Vladislav Shpilevoy via Tarantool-patches 2021-06-16 8:02 ` Cyrill Gorcunov via Tarantool-patches 2021-06-16 23:32 ` Vladislav Shpilevoy via Tarantool-patches [this message] 2021-06-11 21:56 ` [Tarantool-patches] [PATCH 05/13] diag: introduce diag_set_detailed() Vladislav Shpilevoy via Tarantool-patches 2021-06-11 21:56 ` [Tarantool-patches] [PATCH 06/13] wal: encapsulate ER_WAL_IO Vladislav Shpilevoy via Tarantool-patches 2021-06-11 21:56 ` [Tarantool-patches] [PATCH 07/13] txn: change limbo rollback check in the trigger Vladislav Shpilevoy via Tarantool-patches 2021-06-11 21:56 ` [Tarantool-patches] [PATCH 08/13] journal: introduce proper error codes Vladislav Shpilevoy via Tarantool-patches 2021-06-11 21:56 ` [Tarantool-patches] [PATCH 09/13] txn: assert after WAL write that txn is not done Vladislav Shpilevoy via Tarantool-patches 2021-06-15 13:43 ` [Tarantool-patches] [PATCH 00/13] Applier rollback reason Serge Petrenko via Tarantool-patches 2021-06-16 23:32 ` Vladislav Shpilevoy via Tarantool-patches
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=c3ea0f6b-02d8-4bcc-e578-1af7bda0cda3@tarantool.org \ --to=tarantool-patches@dev.tarantool.org \ --cc=gorcunov@gmail.com \ --cc=v.shpilevoy@tarantool.org \ --subject='Re: [Tarantool-patches] [PATCH 04/13] wal: refactor wal_write_to_disk()' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox