Re: make MaxBackends available in _PG_init - Mailing list pgsql-hackers

From Robert Haas
Subject Re: make MaxBackends available in _PG_init
Date
Msg-id CA+TgmoZM7=VoAey4rf+sZEKFpGDWhqEqk_MHoBPXkYbAONGcyQ@mail.gmail.com
Whole thread Raw
In response to Re: make MaxBackends available in _PG_init  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: make MaxBackends available in _PG_init  (Nathan Bossart <nathandbossart@gmail.com>)
List pgsql-hackers
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?

-- 
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: make MaxBackends available in _PG_init
Next
From: "Jonathan S. Katz"
Date:
Subject: Re: How about a psql backslash command to show GUCs?