Re: BUG #17462: Invalid memory access in heapam_tuple_lock
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: anisimow.d@gmail.com
Cc: pgsql-bugs@lists.postgresql.org
Date: 2022-04-11T15:55:19Z
Lists: pgsql-bugs
PG Bug reporting form <noreply@postgresql.org> writes: > When running parallel queries using pgbench with valgrind-enabled server: > pgbench -i -s 1 > pgbench -t 1000 -c 10 -j 10 > I get: > ==00:00:03:09.642 456530== Invalid read of size 2 Reproduced here. It's surprising that nobody noticed this before, because AFAICS the bug is pretty old: it dates to somebody foolishly deciding that heap_fetch didn't need its keep_buf argument, which evidently happened in v12 (didn't track down the exact commit yet). As you say, valgrind would not have caught this problem before 1e0dfd166, but that's not so new anymore either. 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. My inclination for a fix is to revert the removal of the keep_buf argument and go back to having heapam_tuple_lock and other callers release the buffer after they are done. However, that's problematic in released branches, because it seems likely that there are outside callers of heap_fetch. Can we get away with only fixing this in HEAD? regards, tom lane
Commits
-
Prevent access to no-longer-pinned buffer in heapam_tuple_lock().
- 7b7ed046cb2a 15.0 landed
- e0ed20d0b66e 12.11 landed
- c590e514a90d 14.3 landed
- 44096c31eaf0 13.7 landed
-
Add Valgrind buffer access instrumentation.
- 1e0dfd166b3f 14.0 cited
-
tableam: Add tuple_{insert, delete, update, lock} and use.
- 5db6df0c0117 12.0 cited