Re: Disabling ALTER SYSTEM SET WAS: Re: ALTER SYSTEM SET command to change postgresql.conf parameters - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Disabling ALTER SYSTEM SET WAS: Re: ALTER SYSTEM SET command to change postgresql.conf parameters
Date
Msg-id 20130806183147.GV11189@momjian.us
Whole thread Raw
In response to Re: Disabling ALTER SYSTEM SET WAS: Re: ALTER SYSTEM SET command to change postgresql.conf parameters  (Josh Berkus <josh@agliodbs.com>)
Responses Re: Disabling ALTER SYSTEM SET WAS: Re: ALTER SYSTEM SET command to change postgresql.conf parameters  (Claudio Freire <klaussfreire@gmail.com>)
List pgsql-hackers
On Tue, Aug  6, 2013 at 10:33:20AM -0700, Josh Berkus wrote:
> 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 wish I had good news to "say well".  ;-)

> 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.

One of the traps here is that while it makes it easier, it also could
trap the user if they don't have the knowledge to fix a problem because
would need to acquire the knowledge while they are trying to fix the
problem, rather then while they are making the initial change.
> (2) Enabling DBAAS services to give users limited control over settings.

Right.  This could be accomplished by giving users a function API for
certain features, and then marking the function as SECURITY DEFINER. 
However, I am unclear how to do this in a generic way.

Once neat idea would be to have a lookup table define which setting the
administrator wishes to allow for non-superusers.  If adminpack has an
API to change postgresql.conf, it would be easy to create a function
with SECURITY DEFINER permissions that SET lookup-allowed values in
postgresql.conf.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])
Next
From: Robert Haas
Date:
Subject: Re: latest pgbench results