Re: Possibility to disable `ALTER SYSTEM`

Поиск
Список
Период
Сортировка
От Jelte Fennema-Nio
Тема Re: Possibility to disable `ALTER SYSTEM`
Дата
Msg-id CAGECzQR4OC9ieo+m5+eY5tSdP5QUsYKsDN5TOM4az+oC1UQvqg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Possibility to disable `ALTER SYSTEM`  (Peter Eisentraut <peter@eisentraut.org>)
Ответы Re: Possibility to disable `ALTER SYSTEM`  (Peter Eisentraut <peter@eisentraut.org>)
Re: Possibility to disable `ALTER SYSTEM`  (Gabriele Bartolini <gabriele.bartolini@enterprisedb.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: clarify equalTupleDescs()
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock