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
