On Wed, 7 Feb 2024 at 11:16, Peter Eisentraut <peter@eisentraut.org> wrote:
> On 06.02.24 16:22, Jelte Fennema-Nio wrote:
> > On Tue, 30 Jan 2024 at 18:49, Robert Haas <robertmhaas@gmail.com> wrote:
> >> I also think that using the GUC system to manage itself is a little
> >> bit suspect. I wonder if it would be better to do this some other way,
> >> e.g. a sentinel file in the data directory. For example, suppose we
> >> refuse ALTER SYSTEM if $PGDATA/disable_alter_system exists, or
> >> something like that.
> > I'm not convinced we need a new file to disable ALTER SYSTEM. I feel
> > like an "enable_alter_system" GUC that defaults to ON would work fine
> > for this. If we make that GUC be PGC_POSTMASTER then an operator can
> > disable ALTER SYSTEM either with a command line argument or by
> > changing the main config file. Since this feature is mostly useful
> > when the config file is managed by an external system, it seems rather
> > simple for that system to configure one extra GUC in the config file.
>
> Yeah, I'm all for that, but some others didn't like handling this in the
> GUC system, so I'm throwing around other ideas.
Okay, then we're agreeing here. Reading back the email thread the only
argument against GUCs that I could find was Robert thinking it is a "a
little bit suspect" to let the GUC system manage itself. This would
not be the first time we're doing that though, the same is true for
"config_file" and "data_directory" (which even needed the introduction
of GUC_DISALLOW_IN_AUTO_FILE).
So, I personally would like to hear some other options before we start
entertaining some new ways of configuring Postgres its behaviour (even
the read-only postgresql.auto.conf seems quite strange to me).