Re: room for improvement in amcheck btree checking?

On 2020-Dec-01, Mark Dilger wrote:

> 7) Run a SQL query that uses an index scan on the table and see that it errors with something like:
>
> ERROR: could not read block 0 in file "base/13097/16391": read only 0 of 8192 bytes
>
> I found it surprising that even when precisely zero of the tids in the
> index exist in the table the index checks all come back clean.

Yeah, I've seen this kind of symptom in production databases (indexes
pointing to non-existant heap pages).

I think one useful cross-check that amcheck could do, is verify that if
a heap page is referenced from the index, then the heap page must exist.
Otherwise, it's a future index corruption of sorts: the old index
entries will point to the wrong new heap tuples as soon as the table
grows again.