Re: make MaxBackends available in _PG_init - Mailing list pgsql-hackers

From Julien Rouhaud
Subject Re: make MaxBackends available in _PG_init
Date
Msg-id 20220323045229.i23skfscdbvrsuxa@jrouhaud
Whole thread Raw
In response to Re: make MaxBackends available in _PG_init  (Nathan Bossart <nathandbossart@gmail.com>)
Responses Re: make MaxBackends available in _PG_init
List 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 by date:

Previous
From: Bharath Rupireddy
Date:
Subject: Re: add checkpoint stats of snapshot and mapping files of pg_logical dir
Next
From: Japin Li
Date:
Subject: Re: Support logical replication of DDLs