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