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

From Euler Taveira
Subject Re: Possibility to disable `ALTER SYSTEM`
Date
Msg-id 6f7282ca-d9ec-4891-bb38-0f056bbdf5a0@app.fastmail.com
Whole thread Raw
In response to Re: Possibility to disable `ALTER SYSTEM`  (Jelte Fennema-Nio <postgres@jeltef.nl>)
List pgsql-hackers
On Wed, Feb 7, 2024, at 10:49 AM, Jelte Fennema-Nio wrote:
On Wed, 7 Feb 2024 at 11:35, Gabriele Bartolini
> This is mostly the approach I have taken in the patch, except allowing to change the value in the configuration file.

(I had missed the patch in the long thread). I think it would be nice
to have this be PGC_SIGHUP, and set GUC_DISALLOW_IN_AUTO_FILE. That
way this behaviour can be changed without shutting down postgres (but
not with ALTER SYSTEM, because that seems confusing).

Based on Gabriele's use case (Kubernetes) and possible others like a cloud
vendor, I think it should be more restrictive not permissive. I mean,
PGC_POSTMASTER and *only* allow this GUC to be from command-line. (I don't
inspect the code but maybe setting GUC_DISALLOW_IN_FILE is not sufficient to
accomplish this goal.) The main advantages of the GUC system are (a) the
setting is dynamically assigned during startup and (b) you can get the current
setting via SQL.

Another idea is to set it per cluster during initdb like data checksums. You
don't rely on the GUC system but store this information into pg_control. I
think for the referred use cases, you will never have to change it but you can
have a mechanism to change it.


--
Euler Taveira

pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: common signal handler protection
Next
From: Nathan Bossart
Date:
Subject: Re: common signal handler protection