On Wed, Jan 31, 2024 at 5:16 AM Gabriele Bartolini <gabriele.bartol...@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 to disable 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 immediately bails 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
