Re: ERROR: found unexpected null value in index

Andres Freund <andres@anarazel.de> writes:
> On July 10, 2019 1:25:49 PM PDT, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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.

> Well, if we defined i the snapshot semantics as "return rows that are not vacuumable and safe for selfuncs.c
considerations"it seems like a visibility concern if you squint a tiny bit. It's a mostly checking for certain kinds of
deadrows, after all. 

Hm, maybe.  I was considering making it work like "apply
SnapshotNonVacuumable if the tuple isn't HOT_UPDATED, but some stricter
liveness check if it is".  It didn't seem like there was much to be gained
that way given how HeapTupleHeaderIsHotUpdated works ... or, perhaps,
you could say that HeapTupleHeaderIsHotUpdated is already applying a very
strict liveness check.

>> Also, snapshot
>> checking isn't really below the AM API anyway is it?

> It is, imo.

Ah, I see HeapTupleSatisfiesVisibility has already been pushed down
below that horizon.  So I agree, we might be able to finesse this by
pushing the hot-update consideration into HeapTupleSatisfiesNonVacuumable,
or making another snapshot_type that does what we need.

>> 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.

> Hm, that doesn't sound like a trivial change.

Not sure.  We know we're dealing with btree, and it can always do
index-only scans, so it's certainly possible.  But the relevant
APIs might not be conducive to getting what we want.

            regards, tom lane