Re: BTree index corruption (heap-tid-past-end, unexpected zero page, misplaced TID in posting list) recurring on high-churn tables, PG 18.3, data_checksums=on, no preceding crash

On Thu, Jul 2, 2026 at 2:25 PM Alessandro Regolini
<alessandro(at)regolini(dot)it> wrote:
> What we can provide on the next occurrence
> ------------------------------------------
> We run a periodic amcheck sweep, so we usually catch a fresh case before
> reindexing. Before REINDEX we can capture, for the affected block:
> - contrib/pageinspect: bt_page_items() of the index block and
> heap_page_items() / page_header() of the referenced heap block
> - full bt_index_check / bt_index_parent_check output
> - verify_heapam() of the underlying table
> Please tell us which dumps would be most useful to root-cause this (btree
> deduplication / VACUUM interaction is our current suspicion).

Those all seem useful, but I doubt that bt_index_parent_check is going
to add much over bt_index_check. However, you should be sure to run
bt_index_check with heapallindexed=true, which will verify agreement
between the index and the underlying table.

If you see a heapallindexed=true failure, getting page images for the
pointed-to heap page is useful (as well as the index page). I prefer a
raw dump of the page itself over a textual representation. See the
procedure here:

https://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Linux/BSD#contrib/pageinspect_page_dump

--
Peter Geoghegan