Re: make MaxBackends available in _PG_init
От | Nathan Bossart |
---|---|
Тема | Re: make MaxBackends available in _PG_init |
Дата | |
Msg-id | 20220414162215.GB2163833@nathanxps13 обсуждение исходный текст |
Ответ на | Re: make MaxBackends available in _PG_init (Julien Rouhaud <rjuju123@gmail.com>) |
Ответы |
Re: make MaxBackends available in _PG_init
|
Список | 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 по дате отправления: