Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]

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.