Re: Possibility to disable `ALTER SYSTEM`

Поиск
Список
Период
Сортировка
От Euler Taveira
Тема Re: Possibility to disable `ALTER SYSTEM`
Дата
Msg-id 6f7282ca-d9ec-4891-bb38-0f056bbdf5a0@app.fastmail.com
обсуждение исходный текст
Ответ на Re: Possibility to disable `ALTER SYSTEM`  (Jelte Fennema-Nio <postgres@jeltef.nl>)
Список pgsql-hackers
On Wed, Feb 7, 2024, at 10:49 AM, Jelte Fennema-Nio wrote:
On Wed, 7 Feb 2024 at 11:35, Gabriele Bartolini
> This is mostly the approach I have taken in the patch, except allowing to change the value in the configuration file.

(I had missed the patch in the long thread). I think it would be nice
to have this be PGC_SIGHUP, and set GUC_DISALLOW_IN_AUTO_FILE. That
way this behaviour can be changed without shutting down postgres (but
not with ALTER SYSTEM, because that seems confusing).

Based on Gabriele's use case (Kubernetes) and possible others like a cloud
vendor, I think it should be more restrictive not permissive. I mean,
PGC_POSTMASTER and *only* allow this GUC to be from command-line. (I don't
inspect the code but maybe setting GUC_DISALLOW_IN_FILE is not sufficient to
accomplish this goal.) The main advantages of the GUC system are (a) the
setting is dynamically assigned during startup and (b) you can get the current
setting via SQL.

Another idea is to set it per cluster during initdb like data checksums. You
don't rely on the GUC system but store this information into pg_control. I
think for the referred use cases, you will never have to change it but you can
have a mechanism to change it.


--
Euler Taveira

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Nathan Bossart
Дата:
Сообщение: Re: common signal handler protection
Следующее
От: Nathan Bossart
Дата:
Сообщение: Re: common signal handler protection