On Wednesday, March 13, 2013 8:06 PM Andres Freund wrote: > 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.
I checked in ProcessConfigFile(), error level will be DEBUG2 for IsUnderPostmaster. So it should not be a problem. There is another observation from Greg Smith's test-7 (refer his Review mail), that if we call pg_reload_conf() after SET Persistent, it is probably causing some memory leak which leads to delay of further connections. I am checking that problem that why calling pg_reload_conf() leads to memory increase which further causes delay in connection. I think once the reason for same is clear, we can decide on how to load conf file after command execution. With Regards, Amit Kapila. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers