Re: make MaxBackends available in _PG_init

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: make MaxBackends available in _PG_init
Дата
Msg-id 918045.1649797122@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: make MaxBackends available in _PG_init  (Nathan Bossart <nathandbossart@gmail.com>)
Ответы Re: make MaxBackends available in _PG_init  (Nathan Bossart <nathandbossart@gmail.com>)
Re: make MaxBackends available in _PG_init  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Nathan Bossart <nathandbossart@gmail.com> writes:
> I think it'd be reasonable to allow changing custom GUCs in _PG_init().
> Those aren't going to impact things like MaxBackends.

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.

            regards, tom lane



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

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