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

From: Josh Berkus <josh(at)agliodbs(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Cédric Villemain <cedric(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org, Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, 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>
Subject: Re: Disabling ALTER SYSTEM SET WAS: Re: ALTER SYSTEM SET command to change postgresql.conf parameters
Date: 2013-08-06 17:33:20
Message-ID: 52013360.2040100@agliodbs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 08/06/2013 05:29 AM, Bruce Momjian wrote:
> Let's look at the problems:
>
> * remote users can lock themselves out of the server
> * interconnected GUC variables are complex to change
> * need a way to disable this feature
>
> Given the above, I am not sure I see a way forward for ALTER SYSTEM SET.
> One compromise that avoids the problems above would be to have a limited
> feature called ALTER LOG SET that only controls logging parameters, but
> I am not sure there is enough use-case there.
>
> This is not a zero-cost feature as we would be giving people _two_ ways
> to configure Postgres, and two ways to find a fix if it is broken, so we
> have to have a clear win to implement this. Also, if you have broken
> the system via ALTER SYSTEM SET, you might need to edit flat files to
> fix it, adding further complexity and limitations if someone only knows
> the SQL method of configuration. Given that, and the problems above, I
> reluctantly just don't see how this features moves us forward.

Well said.

I'd like to look at use cases, and let's see how ALTER SYSTEM SET
addresses or doesn't address these use cases. I'd really like it if
some other folks also posted use cases they know of.

(1) Making is easier for GUIs to manage PostgreSQL settings.

(2) Enabling DBAAS services to give users limited control over settings.

(3) Making the "initial developer experience" better by not requiring
hand-editing of configuration files to play with settings.

(4) Making it easier to write automated testing scripts which test
changes to settings.

(5) Enabling new ways of writing Puppet/Chef/etc. scripts, which can
check a setting before changing it.

For the current patch, it fullfills these use cases as follows:

(1) works, but is ALSO one of the critical problems with the feature.

(2) does not work for this purpose.

(3) works for this purpose.

(4) works for this purpose.

(5) works for this purpose, although it's unclear if it's actually wanted.

Others?

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2013-08-06 17:37:34 Re: latest pgbench results
Previous Message Boszormenyi Zoltan 2013-08-06 16:34:35 Re: Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])