From: Nathan Bossart <nathandbossart@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Bossart, Nathan <bossartn@amazon.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Fujii Masao <masao.fujii@oss.nttdata.com>
Cc: wangsh.fnst@fujitsu.com <wangsh.fnst@fujitsu.com>
Cc: Andres Freund <andres@anarazel.de>
Cc: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Cc: Greg Sabino Mullane <htamfids@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@lists.postgresql.org <pgsql-hackers@lists.postgresql.org>
Subject: Re: make MaxBackends available in _PG_init
Date: Fri, 28 Jan 2022 20:33:42 -0800
Message-ID: <20220129043342.GA89174@nathanxps13> (raw)
In-Reply-To: <YfSkID0m1APm3ZGr@paquier.xyz>
References: <B7E20C65-D0AB-47B2-BC43-A831601711A2@amazon.com>
<01c32f6c-8101-1ce4-8295-534cf067df94@oss.nttdata.com>
<7239E4F9-A46D-4A61-9200-8B1366D03ADB@amazon.com>
<CA+TgmoZoyOKcE4TpAExHNSvfwE8Q_Y-tDvASN783Zb870pwKAA@mail.gmail.com>
<1E960D8B-24D7-43E0-9744-C5F8C52DDEB4@amazon.com>
<Ye+uOIE0TSbHf/FF@paquier.xyz>
<B6186047-CB98-49B1-A2CA-959057703788@amazon.com>
<YfHtpO9+pxsHblmX@paquier.xyz>
<20220127181815.GA551692@nathanxps13>
<YfSkID0m1APm3ZGr@paquier.xyz>
On Sat, Jan 29, 2022 at 11:19:12AM +0900, Michael Paquier wrote:
> On Thu, Jan 27, 2022 at 10:18:15AM -0800, Nathan Bossart wrote:
>> Alright. I think the comment adjustments still apply, so I split those out
>> to a new patch.
>
> Looks fine after a second look, so applied.
Thanks!
> As of the issues of this thread, we really have two things to think
> about:
> 1) How do we want to control the access of some parameters in a
> context or another? One idea would be more control through GUCs, say
> with a set of context-related flags that prevent the read of some
> variables until they are set. We could encourage the use of
> GetConfigOption() for that. For MaxBackends, we could add a read-only
> GUC for this purpose. That's what Andres hinted at upthread, I
> guess.
> 2) How do we deal with unwanted access of shared parameters? This one
> is not really controllable, is it? And we are talking about much more
> than MaxBackends. This could perhaps be addressed with more
> documentation in the headers for the concerned variables, as a first
> step.
Hm. Perhaps we should understand the full scope of the problem first.
What else besides MaxBackends and the shared memory GUCs won't be properly
initialized when the shared_preload_libraries' _PG_init() functions are
called? MaxBackends seems to be the only one that folks have experienced
problems with, which is why I initially zeroed in on it.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: nathandbossart@gmail.com, michael@paquier.xyz, bossartn@amazon.com, robertmhaas@gmail.com, masao.fujii@oss.nttdata.com, wangsh.fnst@fujitsu.com, andres@anarazel.de, bharath.rupireddyforpostgres@gmail.com, htamfids@gmail.com, tgl@sss.pgh.pa.us, pgsql-hackers@lists.postgresql.org
Subject: Re: make MaxBackends available in _PG_init
In-Reply-To: <20220129043342.GA89174@nathanxps13>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox