Re: make MaxBackends available in _PG_init

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: make MaxBackends available in _PG_init
Дата
Msg-id 1088297.1649856441@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: make MaxBackends available in _PG_init  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: make MaxBackends available in _PG_init  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> Hmm. I suppose I was thinking that we'd go the other way around: move
> the call to InitializeMaxBackends() earlier, as proposed previously,
> and add a hook to allow extensions to get control before that point.
> The reason that I like that approach is that I suspect that it's more
> common for extensions to want to size shared memory data structures
> than it is for them to want to change GUCs, and therefore I thought
> that approach would fix things for the most amount of people with the
> least amount of code change. But it seems like maybe Tom thinks I'm
> incorrect about the relative frequency of those things, so I don't
> know.

Maybe I'm missing something, but I figured we'd keep the _PG_init
calls where they are to minimize side-effects, and then add an optional
hook just before/after shared memory size is determined.  Cases that
work well now continue to work well, and cases that don't work so
well can be fixed by making use of the hook.  In particular you
can still do RequestAddinShmemSpace() in _PG_init as long as the
request size doesn't depend on factors that other extensions might
change.  If you're doing something funny then you might need to
postpone RequestAddinShmemSpace till the new hook call.

            regards, tom lane



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Add --{no-,}bypassrls flags to createuser
Следующее
От: Simon Riggs
Дата:
Сообщение: JSON docs: RFC7159 is now superceded