Re: make MaxBackends available in _PG_init

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: make MaxBackends available in _PG_init
Дата
Msg-id 20210802224204.bckcikl45uezv5e4@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: make MaxBackends available in _PG_init  ("Bossart, Nathan" <bossartn@amazon.com>)
Ответы Re: make MaxBackends available in _PG_init  ("Bossart, Nathan" <bossartn@amazon.com>)
Список pgsql-hackers
Hi,

On 2021-08-02 22:35:13 +0000, Bossart, Nathan wrote:
> On 8/2/21, 3:12 PM, "Andres Freund" <andres@anarazel.de> wrote:
> > I think this is overblown. We already size resources *after*
> > shared_preload_libraries' _PG_init() runs, because that's the whole point of
> > shared_preload_libraries. What's proposed in this thread is to *disallow*
> > increasing resource usage in s_p_l _PG_init(), to make one specific case
> > simpler - but it'll actually also make things more complicated, because other
> > resources will still only be sized after all of s_p_l has been processed.
> 
> True.  Perhaps the comments should reference the possibility that a
> library will adjust resource usage to explain why
> InitializeMaxBackends() is where it is.

I've wondered, independent of this thread, about not making MaxBackends
externally visible, and requiring a function call to access it. It should be
easier to find cases of misuse if we errored out when accessed at the wrong
time. And we could use that opportunity to add flags that determine which
types of backends are included (e.g. not including autovac, or additionally
including aux workers or prepared xacts).

Greetings,

Andres Freund



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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Make relfile tombstone files conditional on WAL level
Следующее
От: "Bossart, Nathan"
Дата:
Сообщение: Re: make MaxBackends available in _PG_init