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+TgmoaHucXd1mehdeSUm3eiOSOviC0W8KyYj81FmNGO2RmbJw@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  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, Apr 12, 2022 at 4:58 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> It's reasonable to allow changing *most* GUCs in _PG_init(); let us
> please not break cases that work fine today.
>
> 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.  (An alternative to a new flag bit is to
> subdivide the PGC_POSTMASTER context into two values, but that seems
> like it'd be far more invasive.  A flag bit needn't be user-visible.)
> Then, what we'd need to do is arrange for shared-preload modules to
> receive their _PG_init call before shared memory creation (when they
> can still twiddle such GUCs) and then another callback later.

I dunno, I feel like this is over-engineered. An extra hook wouldn't
really affect anyone who doesn't need to use it, and I doubt that
adapting to it would create much pain for anyone who is knowledgeable
enough to be writing these kinds of extensions in the first place.
This design is something everyone who adds a GUC from now until the
end of the project needs to know about for the benefit of a tiny
number of extension authors who weren't really going to have a big
problem anyway.

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



pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: make MaxBackends available in _PG_init
Next
From: Tom Lane
Date:
Subject: Re: make MaxBackends available in _PG_init