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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +