Re: make MaxBackends available in _PG_init

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: make MaxBackends available in _PG_init
Дата
Msg-id YfSkID0m1APm3ZGr@paquier.xyz
обсуждение исходный текст
Ответ на 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
On Thu, Jan 27, 2022 at 10:18:15AM -0800, Nathan Bossart wrote:
> Alright.  I think the comment adjustments still apply, so I split those out
> to a new patch.

Looks fine after a second look, so applied.

As of the issues of this thread, we really have two things to think
about:
1) How do we want to control the access of some parameters in a
context or another?  One idea would be more control through GUCs, say
with a set of context-related flags that prevent the read of some
variables until they are set.  We could encourage the use of
GetConfigOption() for that.  For MaxBackends, we could add a read-only
GUC for this purpose.  That's what Andres hinted at upthread, I
guess.
2) How do we deal with unwanted access of shared parameters?  This one
is not really controllable, is it?  And we are talking about much more
than MaxBackends.  This could perhaps be addressed with more
documentation in the headers for the concerned variables, as a first
step.
--
Michael

Вложения

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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Is it correct to update db state in control file as "shutting down" during end-of-recovery checkpoint?
Следующее
От: vignesh C
Дата:
Сообщение: Re: Printing backtrace of postgres processes