| 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: | Whole Thread | Raw Message | 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 |