Horton

Re: BUG #17462: Invalid memory access in heapam_tuple_lock

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: anisimow.d@gmail.com, pgsql-bugs@lists.postgresql.org
Date: 2022-04-12T21:40:05Z
Lists: pgsql-bugs

Attachments

I wrote:
> As written here, even though there's no obvious API break, there is
> a subtle change: heap_fetch will now return tuple->t_data = NULL after
> a snapshot failure.  I'm of two minds whether to back-patch that part
> (not doing so would require more changes in heapam_tuple_lock, though).

After further thought I think we shouldn't back-patch that part: it
could easily break code that's functionally correct today, and there
isn't any case that it makes better without caller-code changes.

(I'm not sure what made me think it'd affect heapam_tuple_lock; that
function only cares about the behavior with keep_buf = true.)

Hence, I end up with two different patches for HEAD and the back branches.
In HEAD, we explicitly break heap_fetch compatibility by adding a new
argument, and we can make the commit message note the more subtle change
too.  In the back branches, the behavior of heap_fetch is unchanged
and heapam_tuple_lock has to use heap_fetch_extended.

			regards, tom lane

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.