From: Tom Lane <tgl@sss.pgh.pa.us>
To: anisimow.d@gmail.com
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17462: Invalid memory access in heapam_tuple_lock
Date: Mon, 11 Apr 2022 11:55:19 -0400
Message-ID: <286748.1649692519@sss.pgh.pa.us> (raw)
In-Reply-To: <17462-9c98a0f00df9bd36@postgresql.org>
References: <17462-9c98a0f00df9bd36@postgresql.org>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, anisimow.d@gmail.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17462: Invalid memory access in heapam_tuple_lock
In-Reply-To: <286748.1649692519@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox