On Mon, Apr 11, 2022 at 8:55 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> In principle, this is showing an actual bug, because once we drop
> the buffer pin somebody could replace the page before we get done
> examining the tuple. I'm not sure what the odds are of that happening
> in the field, but they're probably mighty low because a just-accessed
> buffer should not be high priority for replacement.
I imagine that the greater risk comes from concurrent opportunistic
pruning. The other backend's page defragmentation step (from pruning)
would render our backend's HeapTuple pointer invalid. Presumably it
would just look like an invalid/non-matching xmin in our backend, at
the point of control flow that Valgrind complains about
(heapam_handler.c:509).
--
Peter Geoghegan
