Re: Possibility to disable `ALTER SYSTEM`

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: Possibility to disable `ALTER SYSTEM`
Дата
Msg-id e1198838-8b42-4d62-801c-c4bfb3eb6532@eisentraut.org
обсуждение исходный текст
Ответ на Re: Possibility to disable `ALTER SYSTEM`  (Gabriele Bartolini <gabriele.bartolini@enterprisedb.com>)
Ответы Re: Possibility to disable `ALTER SYSTEM`  ("David G. Johnston" <david.g.johnston@gmail.com>)
Re: Possibility to disable `ALTER SYSTEM`  (Jelte Fennema-Nio <postgres@jeltef.nl>)
Список pgsql-hackers
On 31.01.24 11:16, Gabriele Bartolini wrote:
> I very much like the idea of a file in the data directory that also 
> controls the copy operations.
> 
> Just wanted to highlight though that in our operator we have already 
> applied the read-only postgresql.auto.conf trick to disable the system 
> (see 
> https://cloudnative-pg.io/documentation/current/postgresql_conf/#enabling-alter-system
<https://cloudnative-pg.io/documentation/current/postgresql_conf/#enabling-alter-system>).However, having that file
read-onlytriggered an issue when using pg_rewind to resync a former primary, as pg_rewind immediately bails out when a
read-onlyfile is encountered in the PGDATA (see https://github.com/cloudnative-pg/cloudnative-pg/issues/3698
<https://github.com/cloudnative-pg/cloudnative-pg/issues/3698>).
> 
> We might keep this in mind if we go down the path of the separate file.

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.





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

Предыдущее
От: Mats Kindahl
Дата:
Сообщение: glibc qsort() vulnerability
Следующее
От: "David G. Johnston"
Дата:
Сообщение: Re: Possibility to disable `ALTER SYSTEM`