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

From Alvaro Herrera
Subject Re: Possibility to disable `ALTER SYSTEM`
Date
Msg-id 202309081455.mjyy7fyeb7xb@alvherre.pgsql
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`
List pgsql-hackers
On 2023-Sep-08, Gabriele Bartolini wrote:

> That is the point I highlighted in the initial post in the thread. We could
> make it readonly, but the returned error is misleading and definitely poor
> UX:
> 
> ```
> postgres=# ALTER SYSTEM SET wal_level TO minimal;
> ERROR:  could not open file "postgresql.auto.conf": Permission denied
> ```
> 
> IMO we should clearly state that `ALTER SYSTEM` is deliberately disabled in
> a system, rather than indirectly hinting it through an inaccessible file.
> Not sure if I am clearly highlighting the fine difference here.

Come on. This is not a "fine difference" -- it's the difference between
a crummy hack and a real implementation of an important system
restriction.

I don't understand Tom's resistance to this request.  I understand the
use case and I agree with Gabriele that this is a very simple code
change(*) that Postgres could make to help it get run better in a
different kind of environment than what we're accustomed to.

I've read that containers people consider services in a different light
than how we've historically seen them; they say "cattle, not pets".
This affects the way you think about these services.  postgresql.conf
(all the PG configuration, really) is just a derived file from an
overall system description that lives outside the database server.  You
no longer feed your PG servers one by one, but rather they behave as a
herd, and the herder is some container supervisor (whatever it's called).

Ensuring that the configuration state cannot change from within is
important to maintain the integrity of the service.  If the user wants
to change things, the tools to do that are operated from outside; this
lets things like ancillary services to be kept in sync (say, start a
replica here, or a backup system there, or WAL archival/collection is
handled in this or that way).  If users are allowed to change the config
from within they break things, and the supervisor program can't put
things together again.


I did not like the mention of COPY PROGRAM, though, and in principle I
do not support the idea of treating it the same way as ALTER SYSTEM.  If
people are using that to write into postgresql.conf, then they deserve
all the hell they get when their containers break.  I think trying to
restrict this outside of the privilege system is going to be more of a
wart than ALTER SYSTEM.


(*) To be proven.  Let's see the patch.

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/
Syntax error: function hell() needs an argument.
Please choose what hell you want to involve.



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Document that server will start even if it's unable to open some TCP/IP ports
Next
From: Stephen Frost
Date:
Subject: Re: Adding a pg_get_owned_sequence function?