From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
cc: Nathan Bossart <nathandbossart@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
In-reply-to: <CA+TgmoaHucXd1mehdeSUm3eiOSOviC0W8KyYj81FmNGO2RmbJw@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> <20220412195908.GA2064996@nathanxps13> <918045.1649797122@sss.pgh.pa.us> <CA+TgmoaHucXd1mehdeSUm3eiOSOviC0W8KyYj81FmNGO2RmbJw@mail.gmail.com>
Comments: In-reply-to Robert Haas <robertmhaas@gmail.com>
	message dated "Tue, 12 Apr 2022 17:14:34 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <995397.1649799797.1@sss.pgh.pa.us>
Date: Tue, 12 Apr 2022 17:43:17 -0400
Message-ID: <995398.1649799797@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/995398.1649799797%40sss.pgh.pa.us>
Precedence: bulk

Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Apr 12, 2022 at 4:58 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> It seems after a bit of reflection that what we ought to do is identify
>> the subset of PGC_POSTMASTER GUCs that feed into shared memory sizing,
>> mark those with a new GUC flag, and not allow them to be changed after
>> shared memory is set up.

> I dunno, I feel like this is over-engineered.

It probably is.  I'm just offering this as a solution if people want to
insist on a mechanism to prevent unsafe GUC changes.  If we drop the
idea of trying to forcibly prevent extensions from Doing It Wrong,
then we don't need this, only the extra hook.

			regards, tom lane