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.
This also affects HEAP_XMAX_INVALID for committed deletions.
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.
A minor nit: the new error messages do not follow existing style.
I believe this patch set fixes a real bug. Thanks for finding it.
