Re: make MaxBackends available in _PG_init

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: make MaxBackends available in _PG_init
Дата
Msg-id Yj1OOR/oQOrEt7OI@paquier.xyz
обсуждение исходный текст
Ответ на Re: make MaxBackends available in _PG_init  (Julien Rouhaud <rjuju123@gmail.com>)
Ответы Re: make MaxBackends available in _PG_init  (Julien Rouhaud <rjuju123@gmail.com>)
Список pgsql-hackers
On Fri, Mar 25, 2022 at 11:11:46AM +0800, Julien Rouhaud wrote:
> As an example, here's a POC for a new shmem_request_hook hook after _PG_init().
> With it I could easily fix pg_wait_sampling shmem allocation (and checked that
> it's indeed requesting the correct size).

Are you sure that the end of a release cycle is the good moment to
begin designing new hooks?  Anything added is something we are going
to need supporting moving forward.  My brain is telling me that we
ought to revisit the business with GetMaxBackends() properly instead,
and perhaps revert that.

This solution makes me uneasy from the start (already stated
upthread), because it is not a solution to the original problem, just
a safeguard that handles one small-ish portion of the whole parameter
calculation cycle.
--
Michael

Вложения

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

Предыдущее
От: Greg Stark
Дата:
Сообщение: Re: CREATE INDEX CONCURRENTLY on partitioned index
Следующее
От: Greg Stark
Дата:
Сообщение: Re: Add LZ4 compression in pg_dump