Re: hio.c does visibilitymap_pin()/IO while holding buffer lock - Mailing list pgsql-hackers

From Andres Freund
Subject Re: hio.c does visibilitymap_pin()/IO while holding buffer lock
Date
Msg-id 20230325163903.eu67kqcqo4llhc4u@awork3.anarazel.de
Whole thread Raw
In response to Re: hio.c does visibilitymap_pin()/IO while holding buffer lock  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
Responses Re: hio.c does visibilitymap_pin()/IO while holding buffer lock  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hi,

On 2023-03-25 14:34:25 +0100, Tomas Vondra wrote:
> On 3/25/23 03:57, Andres Freund wrote:
> > 2) Change relevant code so that we only return a valid vmbuffer if we could do
> >    so without blocking / IO and, obviously, skip updating the VM if we
> >    couldn't get the buffer.
> > 
> 
> I don't recall the exact details about the vm locking/pinning, but can't
> we just ensure we actually follow the proper locking order? I mean, this
> only deals with new pages, requested at line ~624:
> 
>   buffer = ReadBufferBI(relation, P_NEW, RBM_ZERO_AND_LOCK, bistate);
> 
> Can't we ensure we actually lock the vm buffer too in ReadBufferBI,
> before calling ReadBufferExtended? Or am I confused and that's not
> possible for some reason?

Note that this is using P_NEW. I.e. we don't know the buffer location yet.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: meson/msys2 fails with plperl/Strawberry
Next
From: Tom Lane
Date:
Subject: Re: hio.c does visibilitymap_pin()/IO while holding buffer lock