Re: Possibility to disable `ALTER SYSTEM`

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Possibility to disable `ALTER SYSTEM`
Дата
Msg-id CA+TgmoZmVQ3mz-o02YOh7RiS+z3yAic_9c4=-1C7F9ufqa5B1g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Possibility to disable `ALTER SYSTEM`  (Gabriele Bartolini <gabriele.bartolini@enterprisedb.com>)
Список pgsql-hackers
On Wed, Jan 31, 2024 at 5:16 AM Gabriele Bartolini
<gabriele.bartolini@enterprisedb.com> 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
todisable the system (see https://cloudnative-pg.io/documentation/current/postgresql_conf/#enabling-alter-system).
However,having that file read-only triggered an issue when using pg_rewind to resync a former primary, as pg_rewind
immediatelybails out when a read-only file is encountered in the PGDATA (see
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.

Yeah. It would be possible to teach pg_rewind and other utilities to
handle unreadable or unwritable files in the data directory, but I'm
not sure that's the best path forward here, and it would require some
consensus that it's the way we want to go.

Another option I thought of would be to control these sorts of things
with a command-line switch. I doubt whether that does anything really
fundamental from a security point of view, but it removes the control
of the toggles from anything in the data directory while still leaving
it within the server administrator's remit.

--
Robert Haas
EDB: http://www.enterprisedb.com



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

Предыдущее
От: Eli Schwartz
Дата:
Сообщение: Re: make dist using git archive
Следующее
От: Matthias van de Meent
Дата:
Сообщение: Re: Reducing output size of nodeToString