Re: make MaxBackends available in _PG_init

Поиск
Список
Период
Сортировка
От Julien Rouhaud
Тема Re: make MaxBackends available in _PG_init
Дата
Msg-id 20220323045229.i23skfscdbvrsuxa@jrouhaud
обсуждение исходный текст
Ответ на 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
Hi,

Sorry for showing up this late, but I'm a bit confused with the new situation.

Unless I'm missing something, the new situation is that the system is supposed
to prevent access to MaxBackends during s_p_l_pg_init, for reasons I totally
agree with, but without doing anything for extensions that actually need to
access it at that time.  So what are extensions supposed to do now if they do
need the information during their _PG_init() / RequestAddinShmemSpace()?

Note that I have two of such extensions.  They actually only need it to give
access to the queryid in the background workers since it's otherwise not
available, but there's at least pg_wait_sampling extension that needs the value
to request shmem for other needs.

One funny note is that my extensions aren't using MaxBackends but instead
compute it based on MaxConnections, autovacuum_max_workers and so on.  So those
two extensions aren't currently broken, or more accurately not more than they
previously were.  Is there any reasoning to not protect all the variables that
contribute to MaxBackends?



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

Предыдущее
От: Bharath Rupireddy
Дата:
Сообщение: Re: add checkpoint stats of snapshot and mapping files of pg_logical dir
Следующее
От: Japin Li
Дата:
Сообщение: Re: Support logical replication of DDLs