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

From Andres Freund
Subject Re: make MaxBackends available in _PG_init
Date
Msg-id 20210802224204.bckcikl45uezv5e4@alap3.anarazel.de
Whole thread Raw
In response to Re: make MaxBackends available in _PG_init  ("Bossart, Nathan" <bossartn@amazon.com>)
Responses Re: make MaxBackends available in _PG_init  ("Bossart, Nathan" <bossartn@amazon.com>)
List 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 by date:

Previous
From: Andres Freund
Date:
Subject: Re: Make relfile tombstone files conditional on WAL level
Next
From: "Bossart, Nathan"
Date:
Subject: Re: make MaxBackends available in _PG_init