Date: Wed, 30 Mar 2022 09:30:51 -0700
From: Nathan Bossart <nathandbossart@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: 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>,
	Tom Lane <tgl@sss.pgh.pa.us>,
	"pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>
Subject: Re: make MaxBackends available in _PG_init
Message-ID: <20220330163051.GA784643@nathanxps13>
References: <20220324202050.GA1855897@nathanxps13>
 <CA+TgmoaonHdak_8utKJCirZNA==62Om_xSnMrm7j2zZox-U8WA@mail.gmail.com>
 <20220325023951.purgu4gb5jyrtc7w@jrouhaud>
 <20220325031146.cd23gaak5qlzdy6l@jrouhaud>
 <Yj1OOR/oQOrEt7OI@paquier.xyz>
 <20220325063542.n6die7fmawluqkfp@jrouhaud>
 <20220325222317.dftrmzuyrb3iv62o@alap3.anarazel.de>
 <20220326072203.asge6bua7dxczf7m@jrouhaud>
 <20220326172316.obspcdmjqerislri@alap3.anarazel.de>
 <CA+Tgmoawc-4i3uFkNdwp8wUR9-jmfV0xjKDyJvGR9t2k2f=1EQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <CA+Tgmoawc-4i3uFkNdwp8wUR9-jmfV0xjKDyJvGR9t2k2f=1EQ@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/20220330163051.GA784643%40nathanxps13>
Precedence: bulk

On Tue, Mar 29, 2022 at 12:22:21PM -0400, Robert Haas wrote:
> It's not, though, because the original proposal was to change things
> around so that the value of MaxBackends would have been reliable in
> _PG_init(). If we'd done that, then extensions that are using it in
> _PG_init() would have gone from being buggy to being not-buggy. But
> since you advocated against that change, we instead committed
> something that caused them to go from being buggy to failing outright.
> That's pretty painful for people with such extensions. And IMHO, it's
> *much* more legitimate to want to size a data structure based on the
> value of MaxBackends than it is for extensions to override GUC values.
> If we can make the latter use case work in a sane way, OK, although I
> have my doubts about how sane it really is, but it can't be at the
> expense of telling extensions that have been (incorrectly) using
> MaxBackends in _PG_init() that we're throwing them under the bus.
> 
> IMHO, the proper thing to do if certain GUC values are required for an
> extension to work is to put that information in the documentation and
> error out at an appropriate point if the user does not follow the
> directions. Then this issue does not arise. But there's no reasonable
> workaround for being unable to size data structures based on
> MaxBackends.

FWIW I would be on board with reverting all the GetMaxBackends() stuff if
we made the value available in _PG_init() and stopped supporting GUC
overrides by extensions (e.g., ERROR-ing in SetConfigOption() when
process_shared_preload_libraries_in_progress is true).

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