Horton

Re: Possibility to disable `ALTER SYSTEM`

Jelte Fennema-Nio <postgres@jeltef.nl>

View thread
From: Jelte Fennema-Nio <postgres@jeltef.nl>
To: Peter Eisentraut <peter@eisentraut.org>
Cc: Gabriele Bartolini <gabriele.bartolini@enterprisedb.com>, Tom Lane <tgl@sss.pgh.pa.us>, "David G. Johnston" <david.g.johnston@gmail.com>, Magnus Hagander <magnus@hagander.net>, Robert Haas <robertmhaas@gmail.com>, Martín Marqués <martin.marques@gmail.com>, Isaac Morland <isaac.morland@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2024-02-07T13:31:28Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Add allow_alter_system GUC.

  2. Rename COMPAT_OPTIONS_CLIENT to COMPAT_OPTIONS_OTHER.

  3. Remove support for version-0 calling conventions.

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).