Re: Disabling ALTER SYSTEM SET WAS: Re: ALTER SYSTEM SET command to change postgresql.conf parameters

From: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)2ndquadrant(dot)com>, Greg Stark <stark(at)mit(dot)edu>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila(at)huawei(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Disabling ALTER SYSTEM SET WAS: Re: ALTER SYSTEM SET command to change postgresql.conf parameters
Date: 2013-08-05 20:18:35
Message-ID: m2pptr7uxw.fsf@2ndQuadrant.fr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

I'm now completely lost in the current threads. Is there a single valid
use case for the feature we're trying to design? Who is the target
audience of this patch?

Josh Berkus <josh(at)agliodbs(dot)com> writes:
> I don't see this as a solution at all. "Mr. Sysadmin, we've given the
> DBAs a new tool which allows them to override your version-controlled
> database parameter settings. You can turn it off, though, by using this
> incredibly complicated, brand-new Event Trigger tool which requires
> writing lots of SQL code to make work."

Well, given what has been said already and very recently again by Tom,
it's superuser only and installing a precedent wherein superuser is not
allowed to use a feature looks like a dead-end. You would have to make a
case that it's comparable to allow_system_table_mods.

If you believe that revoking ALTER SYSTEM SET privileges to superusers
isn't going to be accepted, I know of only two other paths to allow you
to implementing your own policy, including per-GUC policy and
non-superuser granting of ALTER SYSTEM SET in a controled fashion:

- add per GUC GRANT/REVOKE capabilities to SETTINGs,
- implement the same thing within an Event Trigger.

The former has been talked about lots of time already in the past and
I'm yet to see any kind of progress made about it despite plenty of user
support for the feature, the latter requires a shared catalog for global
object Event Triggers and maybe a flexible Extension that you can manage
by just dropping a configuration file into the PostgreSQL conf.d.

So when trying to be realistic the answer is "incredibly complicated"
because it involves a stored procedure to implement the local policy and
a command to enable the policy, really, I wonder who you're addressing
there. Certainly not DBA, so that must be sysadmins, who would be better
off without the feature in the first place if I'm understanding you.

Again, what are we trying to achieve?!

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2013-08-05 20:18:39 Re: make --enable-depend the default
Previous Message Atri Sharma 2013-08-05 20:10:22 Re: Moving 'hot' pages from buffer pool to heap