Re: Possibility to disable `ALTER SYSTEM` - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Possibility to disable `ALTER SYSTEM`
Date
Msg-id e1198838-8b42-4d62-801c-c4bfb3eb6532@eisentraut.org
Whole thread Raw
In response to Re: Possibility to disable `ALTER SYSTEM`  (Gabriele Bartolini <gabriele.bartolini@enterprisedb.com>)
Responses Re: Possibility to disable `ALTER SYSTEM`
Re: Possibility to disable `ALTER SYSTEM`
List pgsql-hackers
On 31.01.24 11:16, Gabriele Bartolini 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
<https://cloudnative-pg.io/documentation/current/postgresql_conf/#enabling-alter-system>).However, having that file
read-onlytriggered an issue when using pg_rewind to resync a former primary, as pg_rewind immediately bails out when a
read-onlyfile is encountered in the PGDATA (see https://github.com/cloudnative-pg/cloudnative-pg/issues/3698
<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.

How about ALTER SYSTEM is disabled if the file 
postgresql.auto.conf.disabled exists? This is somewhat similar to making 
the file read-only, but doesn't risk other tools breaking when they 
encounter such a file.  And it's more obvious and self-explaining.





pgsql-hackers by date:

Previous
From: Mats Kindahl
Date:
Subject: glibc qsort() vulnerability
Next
From: "David G. Johnston"
Date:
Subject: Re: Possibility to disable `ALTER SYSTEM`