Re: BUG #17462: Invalid memory access in heapam_tuple_lock

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: anisimow(dot)d(at)gmail(dot)com, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: BUG #17462: Invalid memory access in heapam_tuple_lock
Date: 2022-04-11 16:25:48
Message-ID: CAH2-Wzmsm4sBXM+bdG_U48sWq8R5XY=fF=ZqnL5vKeqDK4X0bA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Mon, Apr 11, 2022 at 8:55 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2022-04-11 16:35:52 Re: BUG #17462: Invalid memory access in heapam_tuple_lock
Previous Message Tom Lane 2022-04-11 16:19:51 Re: BUG #17462: Invalid memory access in heapam_tuple_lock