From: Serge Petrenko <sergepetrenko@tarantool.org> To: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>, Alexander Turenko <alexander.turenko@tarantool.org>, Konstantin Osipov <kostja.osipov@gmail.com> Cc: tarantool-patches@dev.tarantool.org Subject: Re: [Tarantool-patches] [PATCH v2 3/4] wal: wart when trying to write a record with a broken lsn Date: Tue, 18 Feb 2020 20:28:02 +0300 [thread overview] Message-ID: <C1ADC1EB-A31C-4EFA-BE8B-A9C65D6BA66B@tarantool.org> (raw) In-Reply-To: <c19b8c03-d9b1-33eb-70a0-0acc1b59e638@tarantool.org> [-- Attachment #1: Type: text/plain, Size: 3659 bytes --] Hi! Thanks for your review! Please find my answers below, together with an incremental diff. I’ll send v3 shortly. > 16 февр. 2020 г., в 19:15, Vladislav Shpilevoy <v.shpilevoy@tarantool.org> написал(а): > > Hi! Thanks for the patch! I will review other commits when > Kostja is fine with them. > > Since he finished with this one, here is my nit: lets keep > assertion for the debug build. If not this assertion, we > probably wouldn't notice this bug, and may miss future bugs > without it. During running the tests we won't notice a > warning. > > Also we probably should not call vclock_follow() at all, if > lsn is broken. Just keep it as it. It does not look right to Ok > decrease it. And make it panic() in vclock_follow() to catch > other bugs related to it. Kostja was against panicking on the previous review iteration, the assertion is still in `vclock_follow()` > > On 13/02/2020 22:52, sergepetrenko wrote: >> From: Serge Petrenko <sergepetrenko@tarantool.org> >> >> There is an assertion in vclock_follow `lsn > prev_lsn`, which doesn't >> fire in release builds, of course. Let's at least warn the user on an >> attemt to write a record with a duplicate or otherwise broken lsn. >> >> Follow-up #4739 >> --- >> src/box/wal.c | 15 ++++++++++++--- >> 1 file changed, 12 insertions(+), 3 deletions(-) >> >> diff --git a/src/box/wal.c b/src/box/wal.c >> index 0ae66ff32..f8ee2b7d8 100644 >> --- a/src/box/wal.c >> +++ b/src/box/wal.c >> @@ -951,9 +951,18 @@ wal_assign_lsn(struct vclock *vclock_diff, struct vclock *base, >> (*row)->tsn = tsn; >> (*row)->is_commit = row == end - 1; >> } else { >> - vclock_follow(vclock_diff, (*row)->replica_id, >> - (*row)->lsn - vclock_get(base, >> - (*row)->replica_id)); >> + int64_t diff = (*row)->lsn - vclock_get(base, (*row)->replica_id); >> + if (diff <= vclock_get(vclock_diff, >> + (*row)->replica_id)) { >> + say_crit("Attempt to write a broken LSN to WAL:" >> + " replica id: %d, committed lsn: %d," >> + " new lsn %d", (*row)->replica_id, >> + vclock_get(base, (*row)->replica_id) + >> + vclock_get(vclock_diff, >> + (*row)->replica_id), >> + (*row)->lsn); >> + } >> + vclock_follow(vclock_diff, (*row)->replica_id, diff); > > On the summary, lets call follow() in 'else' branch, and add unreachable() > after crit log. I believe `unreachable` doesn’t fit here, since it implies that the code is truly unreachable, while we are trying to catch something that «shouldn’t happen». I’ve even seen a ticket in our repo regarding this misuse. Let’s just leave an `assert(0)` in this branch, unreachable is defined like that anyway. Here are my changes: diff --git a/src/box/wal.c b/src/box/wal.c index f8ee2b7d8..a87aedf1d 100644 --- a/src/box/wal.c +++ b/src/box/wal.c @@ -955,14 +955,16 @@ wal_assign_lsn(struct vclock *vclock_diff, struct vclock *base, if (diff <= vclock_get(vclock_diff, (*row)->replica_id)) { say_crit("Attempt to write a broken LSN to WAL:" - " replica id: %d, committed lsn: %d," + " replica id: %d, confirmed lsn: %d," " new lsn %d", (*row)->replica_id, vclock_get(base, (*row)->replica_id) + vclock_get(vclock_diff, (*row)->replica_id), (*row)->lsn); + assert(0); + } else { + vclock_follow(vclock_diff, (*row)->replica_id, diff); } - vclock_follow(vclock_diff, (*row)->replica_id, diff); } } } -- Serge Petrenko sergepetrenko@tarantool.org [-- Attachment #2: Type: text/html, Size: 22757 bytes --]
next prev parent reply other threads:[~2020-02-18 17:28 UTC|newest] Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-02-13 21:52 [Tarantool-patches] [PATCH v2 0/4] replication: fix applying of rows originating from local instance sergepetrenko 2020-02-13 21:52 ` [Tarantool-patches] [PATCH v2 1/4] box: expose box_is_orphan method sergepetrenko 2020-02-13 21:52 ` [Tarantool-patches] [PATCH v2 2/4] replication: check for rows to skip in applier correctly sergepetrenko 2020-02-14 7:19 ` Konstantin Osipov 2020-02-14 7:29 ` Konstantin Osipov 2020-02-13 21:52 ` [Tarantool-patches] [PATCH v2 3/4] wal: wart when trying to write a record with a broken lsn sergepetrenko 2020-02-14 7:20 ` Konstantin Osipov 2020-02-14 10:46 ` Serge Petrenko 2020-02-16 16:15 ` Vladislav Shpilevoy 2020-02-18 17:28 ` Serge Petrenko [this message] 2020-02-18 21:15 ` Vladislav Shpilevoy 2020-02-19 8:46 ` Serge Petrenko 2020-02-13 21:53 ` [Tarantool-patches] [PATCH v2 4/4] replication: do not promote local_vclock_at_subscribe unnecessarily sergepetrenko 2020-02-14 7:25 ` Konstantin Osipov 2020-02-14 10:46 ` Serge Petrenko 2020-02-14 10:52 ` Konstantin Osipov
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=C1ADC1EB-A31C-4EFA-BE8B-A9C65D6BA66B@tarantool.org \ --to=sergepetrenko@tarantool.org \ --cc=alexander.turenko@tarantool.org \ --cc=kostja.osipov@gmail.com \ --cc=tarantool-patches@dev.tarantool.org \ --cc=v.shpilevoy@tarantool.org \ --subject='Re: [Tarantool-patches] [PATCH v2 3/4] wal: wart when trying to write a record with a broken lsn' \ /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