Re: make MaxBackends available in _PG_init - Mailing list pgsql-hackers

From Nathan Bossart
Subject Re: make MaxBackends available in _PG_init
Date
Msg-id 20220414162215.GB2163833@nathanxps13
Whole thread Raw
In response to Re: make MaxBackends available in _PG_init  (Julien Rouhaud <rjuju123@gmail.com>)
Responses Re: make MaxBackends available in _PG_init  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Thu, Apr 14, 2022 at 01:50:24PM +0800, Julien Rouhaud wrote:
> On Wed, Apr 13, 2022 at 11:30:40AM -0700, Nathan Bossart wrote:
>> If we do move forward with the shmem request hook, do we want to disallow
>> shmem requests anywhere else, or should we just leave it up to extension
>> authors to do the right thing?  Many shmem requests in _PG_init() are
>> probably okay unless they depend on MaxBackends or another GUC that someone
>> might change.  Given that, I think I currently prefer the latter (option B
>> from upthread).
> 
> I'd be in favor of a hard break.  There are already multiple extensions that
> relies on non final value of GUCs to size their shmem request.  And as an
> extension author it can be hard to realize that, as those extensions work just
> fine until someone wants to try it with some other extension that changes some
> GUC.  Forcing shmem request in a new hook will make sure that it's *always*
> correct, and that only requires very minimal work on the extension side.

Yeah, this is a good point.  If we're okay with breaking existing
extensions like this, I will work on a patch.

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Intermittent buildfarm failures on wrasse
Next
From: Tom Lane
Date:
Subject: Re: Intermittent buildfarm failures on wrasse