Hi hackers! I was investigating foreign-key violations reported by a user after failover. Some tuples had HEAP_XMIN_INVALID set despite their xmin being committed in pg_xact. During the investigation I found the recent snapshot-export bug thread [0], with a fix already committed.
pg_visibility reported the affected tuples on the standby, but verify_heapam() did not. We routinely run verify_heapam() and would like it to catch this damage without having to scan the same tables again with pg_visibility. PFA a two-patch series. 0001 detects this damage by reporting HEAP_XMIN_INVALID when xmin is known to have committed. It excludes old-style VACUUM FULL tuples and does not treat an assumed commit after pg_xact truncation as evidence of corruption. I think it would be good to have such check backpatched along with the corruption fix. 0002 revisits the related xmin/xmax checks I proposed in 2024 [1]. It checks committed hints against aborted transactions, and invalid xmax hints against committed updaters, including multixact members. I kept these separate so that we can address the known corruption first. The first patch's test also covers HEAP_MOVED_IN, though I'm not sure it's worth adding coverage for this old VACUUM FULL format. I am still thinking about how best to repair the existing damage. Thank you! Best regards, Andrey Borodin. [0] https://postgr.es/m/CAH2-WzmHVeYY%3Dpjz9x8DhhxVjXHX0pvoQ-MdiB1Tt6%3Do2GTiKg%40mail.gmail.com [1] https://postgr.es/m/[email protected]
v1-0001-Detect-incorrect-HEAP_XMIN_INVALID-hints-in-verif.patch
Description: Binary data
v1-0002-Detect-more-inconsistent-transaction-hints-in-ver.patch
Description: Binary data
