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