Horton

Re: Possibility to disable `ALTER SYSTEM`

Robert Haas <robertmhaas@gmail.com>

View thread
From: Robert Haas <robertmhaas@gmail.com>
To: Magnus Hagander <magnus@hagander.net>
Cc: Jelte Fennema-Nio <postgres@jeltef.nl>, Greg Sabino Mullane <htamfids@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Heikki Linnakangas <hlinnaka@iki.fi>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>, Daniel Gustafsson <daniel@yesql.se>, Bruce Momjian <bruce@momjian.us>, Joel Jacobson <joel@compiler.org>, Andrew Dunstan <andrew@dunslane.net>, Gabriele Bartolini <gabriele.bartolini@enterprisedb.com>, Maciek Sakrejda <m.sakrejda@gmail.com>
Date: 2024-03-20T19:52:04Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Add allow_alter_system GUC.

  2. Rename COMPAT_OPTIONS_CLIENT to COMPAT_OPTIONS_OTHER.

  3. Remove support for version-0 calling conventions.

On Wed, Mar 20, 2024 at 3:17 PM Magnus Hagander <magnus@hagander.net> wrote:
> Right, what I meant is that making it a packaging decision is the better place. Wherever it goes, allowing the administrator to choose what fits them should be made possible.

+1. Which is also the justification for this patch, when it comes
right down to it. The administrator gets to decide how the contents of
postgresql.conf are to be managed on their particular installation.
They can decide that postgresql.conf should be writable by the same
user that runs PostgreSQL, or not. And they should also be able to
decide that ALTER SYSTEM is an OK way to change configuration, or that
it isn't. How we enable them to make that decision is a point for
discussion, and how exactly we phrase the documentation is a point for
discussion, but we have no business trying to impose conditions, as if
they're only allowed to make that decision if they conform to some
(IMHO ridiculous) requirements that we dictate from on high. It's
their system, not ours.

I mean, for crying out loud, users can set enable_seqscan=off in
postgresql.conf and GLOBALLY DISABLE SEQUENTIAL SCANS. They can set
zero_damaged_pages=on in postgresql.conf and silently remove vast
quantities of data without knowing that they're doing anything. We
don't even question that stuff ... although we probably should be
questioning the second one, because, in my experience, it's just a
foot-gun and never solves anything. Nonetheless, as of today, we have
it. So somehow we're talking ourselves into believing that letting the
user just shut off ALTER SYSTEM, without taking any other action as a
prerequisite, is more scary than those things.

It's not.

-- 
Robert Haas
EDB: http://www.enterprisedb.com