Hi there, 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. Thanks, Gabriele On Wed, 31 Jan 2024 at 08:43, Peter Eisentraut <pe...@eisentraut.org> wrote: > On 31.01.24 06:28, Tom Lane wrote: > >> The idea of adding a file to the data directory appeals to me. > >> > >> optional_runtime_features.conf > >> alter_system=enabled > >> copy_from_program=enabled > >> copy_to_program=disabled > > ... so, exactly what keeps an uncooperative superuser from > > overwriting that file? > > The point of this feature would be to keep the honest people honest. > > The first thing I did when ALTER SYSTEM came out however many years ago > was to install Nagios checks to warn when postgresql.auto.conf exists. > Because the thing is an attractive nuisance, especially when you want to > do centralized configuration control. Of course you can bypass it using > COPY PROGRAM etc., but then you *know* that you are *bypassing* > something. If you just see ALTER SYSTEM, you'll think, "that is > obviously the appropriate tool", and there is no generally accepted way > to communicate that, in particular environment, it might not be. > > -- Gabriele Bartolini Vice President, Cloud Native at EDB enterprisedb.com
