On 2013-03-13 18:52:48 +0530, Amit Kapila wrote: > On Wednesday, March 13, 2013 6:44 PM Andres Freund wrote: > > On 2013-03-13 18:38:12 +0530, Amit Kapila wrote: > > > On Wednesday, March 13, 2013 6:10 PM Andres Freund wrote: > > > > On 2013-03-12 10:46:53 +0530, Amit Kapila wrote: > > > > > Do you mean to say that because some variables can only be set > > after > > > > restart > > > > > can lead to > > > > > inconsistency, or is it because of asynchronous nature of > > > > pg_reload_conf()? > > > > > > > > As long as SET PERSISTENT cannot be executed inside a transaction - > > or > > > > only takes effect after its end - there doesn't seem to be any > > problem > > > > executing ProcessConfigFile() directly. > > > > > > Do you mean to say we call directly ProcessConfigFile() at end of SET > > > PERSISTENT instead > > > Of pg_reload_conf() but in that case would it load the variables for > > other > > > backends? > > > > I'd say do both. Yes, we would evaluate config potentially twice. Who > > cares. Messages inside non-postmaster environments are only output at > > DEBUG2 > > anyway. > > I could see your point, when you say do both that you want that in current > session, > the values will be immediately available which can make user happy. > However if there is any error during function ProcessConfigFile(), it could > be little inconvenient for user as the setting would have been done in file > but memory > processing has created problem.
But thats pretty independent from this? If anything it allows for *better* reporting of problems since you could convert the log level to WARNING if ProcessConfigFile() is executed in foreground - which at least interactive sessions normally will noramlly be displayed for the user. If you do don't do it immediately you're in the same situation after the pg_reload_config(), just that the user won't see any error messages. There is something I am more worried about which is that it ight be bad if a postmaster child adapts new values bfore postmaster does. I right now can't think of any new dangers since the reverse is already true... Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers