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
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 |