Date: Tue, 12 Apr 2022 14:01:12 -0700
From: Nathan Bossart <nathandbossart@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>, Andres Freund <andres@anarazel.de>,
	Julien Rouhaud <rjuju123@gmail.com>,
	Michael Paquier <michael@paquier.xyz>,
	"Bossart, Nathan" <bossartn@amazon.com>,
	Fujii Masao <masao.fujii@oss.nttdata.com>,
	"wangsh.fnst@fujitsu.com" <wangsh.fnst@fujitsu.com>,
	Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>,
	Greg Sabino Mullane <htamfids@gmail.com>,
	"pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>
Subject: Re: make MaxBackends available in _PG_init
Message-ID: <20220412210112.GA2065815@nathanxps13>
References: 
 <CA+TgmoZRnwF=9tMX0TiqZGC4qAK_27NweKd5r-S=OSaE_nL70A@mail.gmail.com>
 <20220411164408.GA1915258@nathanxps13>
 <CA+TgmoZVQznhWpUr-bjC9U=Won8ZnfozSkiXrW2HU80r6QyASQ@mail.gmail.com>
 <20220411204442.GA2004824@nathanxps13>
 <20220411211435.GA2057981@nathanxps13>
 <20220412174427.sngj2uexzsttazs2@alap3.anarazel.de>
 <20220412180306.GA2063516@nathanxps13>
 <CA+TgmoY4og1VADa78VySwsTjtTQbtXbnRPSq9x=e6ogS_wWfaw@mail.gmail.com>
 <20220412194938.GA2064338@nathanxps13>
 <915771.1649795619@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <915771.1649795619@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/20220412210112.GA2065815%40nathanxps13>
Precedence: bulk

On Tue, Apr 12, 2022 at 04:33:39PM -0400, Tom Lane wrote:
> Nathan Bossart <nathandbossart@gmail.com> writes:
>> On Tue, Apr 12, 2022 at 03:12:42PM -0400, Robert Haas wrote:
>>> But if there's even one use case where adjusting GUCs at this phase is
>>> reasonable, then 0003 isn't really good enough. We need an 0004 that
>>> provides a new hook in a place where such changes can safely be made.
> 
>> I think that is doable.  IMO it should be ѕomething like _PG_change_GUCs()
>> that is called before _PG_init().  The other option is to add a hook called
>> after _PG_init() where MaxBackends is available (in which case we likely
>> want GetMaxBackends() again).  Thoughts?
> 
> I like the second option.  Calling into a module before we've called its
> _PG_init function is just weird, and will cause no end of confusion.

Alright.  I think that is basically what Julien recommended a few weeks ago
[0].  Besides possibly reintroducing GetMaxBackends(), we might also want
to block SetConfigOption() when called in this new hook.

[0] https://postgr.es/m/20220325031146.cd23gaak5qlzdy6l%40jrouhaud

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com