Re: Possibility to disable `ALTER SYSTEM`

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 <peter(at)eisentraut(dot)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