Okay, something else (a real problem this time ;-)):
HeapTupleSatisfiesAbort is bogus because it has failed to track recent
changes in tqual.c.
Rather than fix it, though, I question why we need it at all. The only
use of it is in heap_prune_tuplechain() and ISTM that code is redundant,
wrong, or both.
In the case of a full-page prune, it's redundant because the tuple would
be found anyway by searching its chain from the root tuple. Indeed I
suspect that such a tuple is entered into the newly-dead list twice,
perhaps risking overflow of that array.
In the case of a single-chain prune, it still seems wrong since you'll
eliminate only one of what might be a chain with multiple aborted
entries. If it's OK to leave those other entries for future collection,
then it should be OK to leave this one too. If it's not OK then the
approach needs to be redesigned.
I'm fairly unclear on what the design intention is for recovering from
the case where the last item(s) on a HOT chain are aborted. Please
clarify.
regards, tom lane
