From: Nathan Bossart <nathandbossart@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andres Freund <andres@anarazel.de>
Cc: Julien Rouhaud <rjuju123@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>
Cc: Bossart, Nathan <bossartn@amazon.com>
Cc: Fujii Masao <masao.fujii@oss.nttdata.com>
Cc: wangsh.fnst@fujitsu.com <wangsh.fnst@fujitsu.com>
Cc: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Cc: Greg Sabino Mullane <htamfids@gmail.com>
Cc: pgsql-hackers@lists.postgresql.org <pgsql-hackers@lists.postgresql.org>
Subject: Re: make MaxBackends available in _PG_init
Date: Tue, 12 Apr 2022 12:59:08 -0700
Message-ID: <20220412195908.GA2064996@nathanxps13> (raw)
In-Reply-To: <CA+TgmoZM7=VoAey4rf+sZEKFpGDWhqEqk_MHoBPXkYbAONGcyQ@mail.gmail.com>
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>
<908945.1649791317@sss.pgh.pa.us>
<CA+TgmoZM7=VoAey4rf+sZEKFpGDWhqEqk_MHoBPXkYbAONGcyQ@mail.gmail.com>
On Tue, Apr 12, 2022 at 03:30:23PM -0400, Robert Haas wrote:
> On Tue, Apr 12, 2022 at 3:22 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Yeah. It's a very long way from "changing shared memory sizes here
>> doesn't work" to "no extension is allowed to change any GUC at load
>> time". A counterexample is that it's not clear why an extension
>> shouldn't be allowed to define a GUC using DefineCustomXXXVariable
>> and then immediately set it to some other value. I think trying to
>> forbid that across-the-board is going to mostly result in breaking
>> a lot of cases that are perfectly safe.
>
> Hmm, that's an interesting case which I hadn't considered. It seems
> like sort of a lame thing to do, because why wouldn't you just create
> the GUC with the right initial value instead of modifying it after the
> fact? But maybe there's some use case in which it makes sense to do it
> that way. A read-only GUC that advertises some calculated value,
> perhaps?
I think it'd be reasonable to allow changing custom GUCs in _PG_init().
Those aren't going to impact things like MaxBackends.
--
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, robertmhaas@gmail.com, tgl@sss.pgh.pa.us, andres@anarazel.de, rjuju123@gmail.com, michael@paquier.xyz, bossartn@amazon.com, masao.fujii@oss.nttdata.com, wangsh.fnst@fujitsu.com, bharath.rupireddyforpostgres@gmail.com, htamfids@gmail.com, pgsql-hackers@lists.postgresql.org
Subject: Re: make MaxBackends available in _PG_init
In-Reply-To: <20220412195908.GA2064996@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