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
