Re: amcheck: add index-all-keys-match verification for B-Tree

On Sun, Nov 8, 2026 at 8:23 AM Andrey Borodin <x4mmm(at)yandex-team(dot)ru> wrote:
>
> Hi Jakub,

Hi Andrey,

> On 5 Oct 2026, Jakub Wartak wrote:
> > still follows LP_REDIRECT/HOT
>
> PFA v7 with your API fixup folded into 0001 and the old 0002/0003 merged.
[..]

Cool!

I've found two missing things and I'm attaching as one-off patches for
consideration and some other third small thing:
1) pg_amcheck was missing --indexallkeysmatch support
2) we could check if btree isn't pointing directly to HOT (just in case)

Also I've been throwing this code under a bus a lot at 100MB and 10GB+ scales
with over 10k TPS and vacuum hammering it like crazy for dozen of minutes
(with threshold/scales='1' and with high concurrency pgbench), and I couldn't
find a single false positives being generated: both on primary and standby
with parallel pg_amchecks -j X --indexallkeysmatch , on standby of with with
hot_standby_feedback to avoid rep conflicts).

Also I've made braindump about and come to the conclusion that perhaps the
below table could be part of docs or just having it in the code would be
useful, thoughts on this? (perhaps please double check me on this if we
want to have it in docs)

corruption-kind b_i_c() b_i_parent_c()
lost heap segment/TID beyond end of heap yes* yes*
index<->heapam key mismatch yes yes
TID points to LP_UNUSED no yes
TID offset beyond the page line pointer array no yes
TID points directly at HOT (w/o LP_REDIRECT) no yes

* = even without indexallkeysmatch
b_i_c() b_i_parent_c() stand for shortcuts of SQL function names.

Anyway, I find the tradeoff betwen lock mode (SL vs ASL) and being able to
idenitify corrupted things quite good as it is now. Perhaps, we should set
it as ready for commit now?

Perhaps, qq, should we care if there are other tableAM used with btree
somehow? (I haven't tried that as I'm struggling to find one that works with
master/PG20)

-J.