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 20230325181707.at3kwsh7uvkhfype@awork3.anarazel.de
Whole thread Raw
In response to Re: hio.c does visibilitymap_pin()/IO while holding buffer lock  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: hio.c does visibilitymap_pin()/IO while holding buffer lock  (Peter Geoghegan <pg@bowt.ie>)
Re: hio.c does visibilitymap_pin()/IO while holding buffer lock  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Hi,

On 2023-03-25 12:57:17 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On 2023-03-25 14:34:25 +0100, Tomas Vondra wrote:
> >> 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.
> 
> Maybe the relation-extension logic needs to include the ability to get
> the relevant vm page?

I don't see how that's easily possible with the current lock ordering
rules. At least without giving up using RBM_ZERO_AND_LOCK for extending or
stuffing even more things to happen with the the extension lock held, which I
don't think we want to. I don't think INSERT_FROZEN is worth that price.

Perhaps we should just try to heuristically pin the right VM buffer before
trying to extend?

Thinking more about this, I think there's no inherent deadlock danger with
reading the VM while holding a buffer lock, "just" an efficiency issue. If we
avoid needing to do IO nearly all the time, by trying to pin the right page
before extending, it's probably good enough.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Re: Bug with ICU for merge join
Next
From: Peter Geoghegan
Date:
Subject: Re: hio.c does visibilitymap_pin()/IO while holding buffer lock