Re: File-per-GUC WAS: Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])

On Tue, Aug  6, 2013 at 06:30:18PM +0530, Amit Kapila wrote:
> > Now, I assume that ALTER SYSTEM SET would automatically issue a
> > pg_reload_conf(), so we would need to make sure that people modifying
> > multiple parameters that are related do it in a single transaction, and
> > that we issue a pg_reload_conf() only after all values have been
> > changed.
> 
> Can't we leave this onus of conflict of changing dependent parameters on
> user, such that he should do it carefully?
> Other databases SQL Server, Oracle also has similar feature, so there user's
> also must be handling by themselves.

Yes, we _can_ have the user deal with it, but we have to consider the
final user experience.  The initial experience will be, "Oh, great, no
more need to edit a configuration file,", but it might end with:

*  Oh, my server doesn't start and I don't have shell access
*  How do I undo an ALTER SYSTEM SET if the server can't be started
*  Why doesn't my server start?  postgresql.conf looks fine (see ALTER  SYSTEM SET)
*  What things did I change via ALTER SYSTEM SET
*  How do I disable ALTER SYSTEM SET so only postgresql.conf works

Consider how long it took the hackers to realize all the interactions
involved;  we would have to effectively communicate that to users.

I realize other database systems have this, but those systems are not
known to be easy to use.  ALTER SYSTEM SET has the promise of making
Postgres easier to use, _and_ harder to use.

The question is what percentage of users are going to have a positive
experience with this feature, and what percentage are going to have a
negative or disastrous experience with it, or disable it?

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