Re: Improve search for missing parent downlinks in amcheck

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Improve search for missing parent downlinks in amcheck
Date: 2019-04-28 00:03:39
Message-ID: CAH2-Wz=DPEfP0re3AUBMKrxRjpj0uESM--65VwZcDKhtJBTxVA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Apr 27, 2019 at 4:57 PM Alexander Korotkov
<a(dot)korotkov(at)postgrespro(dot)ru> wrote:
> "rootdescend" is cool type of check. Thank you for noticing, I wasn't aware of it.
> But can it detect the missing downlink in following situation?
>
> A
> / \
> B <-> C <-> D
>
> Here A has downlinks to B and D, which downlink to C is missing,
> while B, C and D are correctly connected with leftlinks and rightlinks.
> I can see "rootdescend" calls _bt_search(), which would just step
> right from C to D as if it was concurrent split.

There is a comment about this scenario above bt_rootdescend() in amcheck.

You're right -- this is a kind of corruption that even the new
rootdescend verification option would miss. We can imagine a version
of rootdescend verification that tells the core code to only move
right when there was an *interrupted* page split (i.e.
P_INCOMPLETE_SPLIT() flag bit is set), but that isn't what happens
right now.

That said, the lossy downlink check that you want to improve on
*should* already catch this situation. Of course it might not because
it is lossy (uses a Bloom filter), but I think that that's very
unlikely. That's why I would like to understand the problem that you
found with the check.

--
Peter Geoghegan

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Korotkov 2019-04-28 00:12:54 Re: Improve search for missing parent downlinks in amcheck
Previous Message Alexander Korotkov 2019-04-27 23:57:11 Re: Improve search for missing parent downlinks in amcheck