On Wed, 7 Feb 2024 at 11:16, Peter Eisentraut <pe...@eisentraut.org> wrote: > On 06.02.24 16:22, Jelte Fennema-Nio wrote: > > On Tue, 30 Jan 2024 at 18:49, Robert Haas <robertmh...@gmail.com> wrote: > >> I also think that using the GUC system to manage itself is a little > >> bit suspect. I wonder if it would be better to do this some other way, > >> e.g. a sentinel file in the data directory. For example, suppose we > >> refuse ALTER SYSTEM if $PGDATA/disable_alter_system exists, or > >> something like that. > > I'm not convinced we need a new file to disable ALTER SYSTEM. I feel > > like an "enable_alter_system" GUC that defaults to ON would work fine > > for this. If we make that GUC be PGC_POSTMASTER then an operator can > > disable ALTER SYSTEM either with a command line argument or by > > changing the main config file. Since this feature is mostly useful > > when the config file is managed by an external system, it seems rather > > simple for that system to configure one extra GUC in the config file. > > Yeah, I'm all for that, but some others didn't like handling this in the > GUC system, so I'm throwing around other ideas.
Okay, then we're agreeing here. Reading back the email thread the only argument against GUCs that I could find was Robert thinking it is a "a little bit suspect" to let the GUC system manage itself. This would not be the first time we're doing that though, the same is true for "config_file" and "data_directory" (which even needed the introduction of GUC_DISALLOW_IN_AUTO_FILE). So, I personally would like to hear some other options before we start entertaining some new ways of configuring Postgres its behaviour (even the read-only postgresql.auto.conf seems quite strange to me).
