Re: hio.c does visibilitymap_pin()/IO while holding buffer lock

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: hio.c does visibilitymap_pin()/IO while holding buffer lock
Дата
Msg-id 20230325181707.at3kwsh7uvkhfype@awork3.anarazel.de
обсуждение исходный текст
Ответ на Re: hio.c does visibilitymap_pin()/IO while holding buffer lock  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы 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>)
Список 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 по дате отправления:

Предыдущее
От: Jeff Davis
Дата:
Сообщение: Re: Bug with ICU for merge join
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: hio.c does visibilitymap_pin()/IO while holding buffer lock