Re: introduce bufmgr hooks - Mailing list pgsql-hackers

From Andres Freund
Subject Re: introduce bufmgr hooks
Date
Msg-id 20220902003403.kczdfdawuihdnrr2@awork3.anarazel.de
Whole thread Raw
In response to Re: introduce bufmgr hooks  (Nathan Bossart <nathandbossart@gmail.com>)
Responses Re: introduce bufmgr hooks
List pgsql-hackers
Hi,

On 2022-09-01 13:11:50 -0700, Nathan Bossart wrote:
> On Wed, Aug 31, 2022 at 08:29:31AM -0700, Andres Freund wrote:
> > I'm very doubtful this is a good idea. These are quite hot paths. While not a
> > huge cost, adding an indirection isn't free nonetheless.
> 
> Are you concerned about the NULL check or the potential hook
> implementations?  I can probably test the former pretty easily, but the
> latter seems like a generic problem for many hooks.

Mostly the former. But the latter is also relevant - the lock nesting etc is
very hard to deal with if you don't know what runs inside.


> > I also think it'll
> > make it harder to improve things in this area, which needs quite a bit of
> > work.
> 
> If you have specific refactoring in mind that you think ought to be a
> prerequisite for this change, I'm happy to give it a try.

There's a few semi-active threads (e.g. about not holding multiple buffer
partition locks). One important change is to split the way we acquire buffers
for file extensions - right now we get a victim buffer while holding the
relation extension lock, because there's simply no API to do otherwise. We
need to change that so we get acquire a victim buffer before holding the
extension lock (with the buffer pinned but not [tag] valid), then we need to
get the extension lock, insert it into its new position in the buffer mapping
table.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: Fix possible bogus array out of bonds (src/backend/access/brin/brin_minmax_multi.c)
Next
From: jadel@mercury.com
Date:
Subject: [PATCH] docs: Document the automatically generated names for indices