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/BE90C4F8-9A37-40AD-A5CC-9818BBE59BCC@yandex-team.ru
