Horton

Re: BUG #17462: Invalid memory access in heapam_tuple_lock

Peter Geoghegan <pg@bowt.ie>

View thread View on postgr.es
From: Peter Geoghegan <pg@bowt.ie>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: anisimow.d@gmail.com, PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Date: 2022-04-11T16:25:48Z
Lists: pgsql-bugs 
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

Commits

  1. Prevent access to no-longer-pinned buffer in heapam_tuple_lock().

  2. Add Valgrind buffer access instrumentation.

  3. tableam: Add tuple_{insert, delete, update, lock} and use.