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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
