Re: make MaxBackends available in _PG_init
От | Robert Haas |
---|---|
Тема | Re: make MaxBackends available in _PG_init |
Дата | |
Msg-id | CA+TgmoYCK9TKxKT_39S7SVD56rgcffFOozzUso2kxStsmvwZRQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: make MaxBackends available in _PG_init (Nathan Bossart <nathandbossart@gmail.com>) |
Ответы |
Re: make MaxBackends available in _PG_init
|
Список | pgsql-hackers |
On Thu, Apr 14, 2022 at 12:22 PM Nathan Bossart <nathandbossart@gmail.com> wrote: > > 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. I tend to think it's a good idea. It's not great to inconvenience extension authors, but I think that with the kind of design we are talking about here it will be pretty straightforward to see how to update your extension: move the code that request shmem resources into the new hook. If you want to be compatible with older PostgreSQL releases by conditional compilation, conditionally call that function from _PG_init() when PG_VERSION_NUM < whatever. Compare that with the current situation, where things seem to mostly work but sometimes don't, and it's not quite clear what to do about it. -- Robert Haas EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: