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.
Ideally, there should not be any error in function ProcessConfigFile(), but
might be some palloc or such call
would be sufficient to make user unhappy.
With Regards,
Amit Kapila.