Andres Freund <andres@anarazel.de> writes:
> On 2019-07-10 16:02:50 -0400, Tom Lane wrote:
>> Should we try to transpose some of this logic to below the AM API,
>> and if so, what should that look like?
> I wonder if we could push this down into a separate type of visibility
> (or maybe redefine NonVacuumable)? So that the scan wouldn't ever
> return them in the first place? It's a bit annoying to have a visibility
> type that's perhaps best called "what selfuncs.c needs", but still seams
> cleaner than having a separate callback? And the explanation for why
> that's possibly needed also seems to better belong inside the AMs.
SnapshotNonVacuumable is already basically "what selfuncs.c needs" ---
nothing else is using it. So I wouldn't hesitate to redefine it if
that'd fix the problem. But it doesn't sound like a promising approach.
The problem here isn't whether the heap tuple is live or dead, it's
whether it can be trusted to match the index entry. Also, snapshot
checking isn't really below the AM API anyway is it?
I wonder if we'd be better off to switch over to using data directly
from the index entry, rather than trying to recover it from the heap.
We'd then need to make sure that the logic exploits btree's "killed
index entry" ability, so that dead extremal values are ignored as
much as possible. But that'd get us out of the broken-HOT-chain
problem.
regards, tom lane