Re: Possibility to disable `ALTER SYSTEM` - Mailing list pgsql-hackers

From Jelte Fennema-Nio
Subject Re: Possibility to disable `ALTER SYSTEM`
Date
Msg-id CAGECzQR4OC9ieo+m5+eY5tSdP5QUsYKsDN5TOM4az+oC1UQvqg@mail.gmail.com
Whole thread Raw
In response to Re: Possibility to disable `ALTER SYSTEM`  (Peter Eisentraut <peter@eisentraut.org>)
Responses Re: Possibility to disable `ALTER SYSTEM`
Re: Possibility to disable `ALTER SYSTEM`
List pgsql-hackers
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.

On Tue, 6 Feb 2024 at 15:10, Peter Eisentraut <peter@eisentraut.org> wrote:
> How about ALTER SYSTEM is disabled if the file
> postgresql.auto.conf.disabled exists? This is somewhat similar to making
> the file read-only, but doesn't risk other tools breaking when they
> encounter such a file.  And it's more obvious and self-explaining.

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.



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: clarify equalTupleDescs()
Next
From: Alvaro Herrera
Date:
Subject: Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock