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