On Thu, Jul 2, 2026 at 2:25 PM Alessandro Regolini
<alessandro@regolini.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
