Re: make MaxBackends available in _PG_init

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: make MaxBackends available in _PG_init
Дата
Msg-id CA+TgmoaHucXd1mehdeSUm3eiOSOviC0W8KyYj81FmNGO2RmbJw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: make MaxBackends available in _PG_init  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: make MaxBackends available in _PG_init  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Tue, Apr 12, 2022 at 4:58 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> It's reasonable to allow changing *most* GUCs in _PG_init(); let us
> please not break cases that work fine today.
>
> It seems after a bit of reflection that what we ought to do is identify
> the subset of PGC_POSTMASTER GUCs that feed into shared memory sizing,
> mark those with a new GUC flag, and not allow them to be changed after
> shared memory is set up.  (An alternative to a new flag bit is to
> subdivide the PGC_POSTMASTER context into two values, but that seems
> like it'd be far more invasive.  A flag bit needn't be user-visible.)
> Then, what we'd need to do is arrange for shared-preload modules to
> receive their _PG_init call before shared memory creation (when they
> can still twiddle such GUCs) and then another callback later.

I dunno, I feel like this is over-engineered. An extra hook wouldn't
really affect anyone who doesn't need to use it, and I doubt that
adapting to it would create much pain for anyone who is knowledgeable
enough to be writing these kinds of extensions in the first place.
This design is something everyone who adds a GUC from now until the
end of the project needs to know about for the benefit of a tiny
number of extension authors who weren't really going to have a big
problem anyway.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Nathan Bossart
Дата:
Сообщение: Re: make MaxBackends available in _PG_init
Следующее
От: Tom Lane
Дата:
Сообщение: Re: make MaxBackends available in _PG_init