Hi, > I would like to propose a patch that allows administrators to disable `ALTER > SYSTEM` via either a runt-time option to pass to the Postgres server process > at startup (e.g. `--disable-alter-system=true`, false by default) or a new > GUC (or even both), without changing the current default method of the server.
I'm actually going to put a strong +1 to Gabriele's proposal. It's an undeniable problem (I'm only seeing arguments regarding other ways the system would be insecure), and there might be real use cases for users outside kubernetes for having this feature and using it (meaning disabling the use of ALTER SYSTEM). In Patroni for example, the PostgreSQL service is controlled on all nodes by Patroni, and these kinds of changes could end up breaking the cluster if there was a failover. For this reason Patroni starts postgres with some GUC options as CMD arguments so that values in postgresql.conf or postgresql.auto.conf are ignored. The values in the DCS are the ones that matter. ``` postgres 1171221 0.0 1.9 903560 55168 ? S 10:16 0:00 /usr/pgsql-15/bin/postgres -D /opt/postgres/data --config-file=/opt/postgres/data/postgresql.conf --listen_addresses=0.0.0.0 --port=5432 --cluster_name=patroni-tpa --wal_level=logical --hot_standby=on --max_connections=250 --max_wal_senders=6 --max_prepared_transactions=0 --max_locks_per_transaction=64 --track_commit_timestamp=off --max_replication_slots=6 --max_worker_processes=16 --wal_log_hints=on ``` (see more about how Patroni manages this here: https://patroni.readthedocs.io/en/latest/patroni_configuration.html#postgresql-parameters-controlled-by-patroni But let's face it, that's a hack, not something to be proud of, even if it does what is intended. And this is a product and we shouldn't be advertising hacks to overcome limitations. I find the opposition to this lacking good reasons, while I find the implementation to be useful in some cases. Kind regards, Martín -- Martín Marqués It’s not that I have something to hide, it’s that I have nothing I want you to see
