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

From Robert Haas
Subject Re: make MaxBackends available in _PG_init
Date
Msg-id CA+TgmoacGW7kGda0DC+JHXKsa6anEUvfuuSenG=FCohRX_NHzA@mail.gmail.com
Whole thread Raw
In response to Re: make MaxBackends available in _PG_init  (Julien Rouhaud <rjuju123@gmail.com>)
List pgsql-hackers
On Wed, Mar 23, 2022 at 12:53 AM Julien Rouhaud <rjuju123@gmail.com> wrote:
> 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()?

Well, the conclusion upthread was that extensions might change the
values of those GUCs from _PG_init(). If that's a real thing, then
what you're asking for here is impossible, because the final value is
indeterminate until all such extensions have finished twiddling those
the GUCs. On the other hand, it's definitely intended that extensions
should RequestAddinShmemSpace() from _PG_init(), and wanting to size
that memory based on MaxBackends is totally reasonable. Do we need to
add another function, alongside _PG_init(), that gets called after
MaxBackends is determined and before it's too late to
RequestAddinShmemSpace()?

-- 
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Justin Pryzby
Date:
Subject: Re: SQL/JSON: functions
Next
From: Ashutosh Bapat
Date:
Subject: Support isEmptyStringInfo