On Sun, Oct 25, 2026 at 8:56 PM Michael Paquier <[email protected]> wrote: > Set HEAP_XMAX_INVALID for tuples updated by aborted subtransaction > > HeapTupleSatisfiesVacuumHorizon() did not set HEAP_XMAX_INVALID on a > tuple inserted, then updated by a subtransaction that rolled back. > rewriteheap.c relies on this hint to tell if such tuples should be > treated as updated and would drop them, causing rewrites to lose some > tuples. > > HeapTupleSatisfiesVacuumHorizon() is updated to set the hint > HEAP_XMAX_INVALID, so as heap AM is able to redirect such a tuple to its > correct route, and does not lose it.
Uggh. I think that this is the right fix given that rewrite_heap_tuple() is documented to rely on hint bits being set for correctness, but it seems to me to be pretty questionable that we rely on hint bits being set for correctness. It's not going to be obvious to someone modifying HeapTupleSatisfiesVacuum() or HeapTupleSatisfiesVacuumHorizon() that rewrite_heap_tuple() critically depends on that, and even if we added a comment about that, somebody reading that comment might justifiably complain about our decision to create such a dependency. -- Robert Haas Databricks
