Thread: Re: [PATCHES] Allow commenting of variables in postgresql.conf to - try 4

Joachim Wieland <joe@mcknight.de> writes:
> I did not check the changes you have done to set_config_option and the like
> but tested the commenting / uncommenting / changing of guc variables and the
> behavior and log output. The general idea (at least my idea) is that
> whenever a SIGHUP is received and there is some difference between the
> config file and the active value that the server is using, a notice message
> is written to the log.

Notice message?  Where did that come from?  The behavior I thought
people were after was just that variables previously defined by the file
would revert to reset values if not any longer defined by the file.

From a reviewer's point of view, it'd be nice if the patch did not
contain so many useless changes of whitespace.

            regards, tom lane

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Joachim Wieland <joe@mcknight.de> writes:
> > I did not check the changes you have done to set_config_option and the like
> > but tested the commenting / uncommenting / changing of guc variables and the
> > behavior and log output. The general idea (at least my idea) is that
> > whenever a SIGHUP is received and there is some difference between the
> > config file and the active value that the server is using, a notice message
> > is written to the log.
>
> Notice message?  Where did that come from?  The behavior I thought
> people were after was just that variables previously defined by the file
> would revert to reset values if not any longer defined by the file.

There's two issues here, I believe.  There's the
'revert-to-reset-values' issue for things which can be changed with a
reload and then there's also the 'notice-message-if-unable-to-change'
a given variable without a reset.

On reload a variable is changed:

#1: That variable can be changed by a reload.
    If the variable has been removed/commented-out then it is reverted
    to the reset-value.  Otherwise, the new value is used.

#2: That variable can *not* be changed by a reload.
    Notice-level message is sent to the log notifying the admin that the
    change requested could not be performed.  This change could be
    either a revert to reset-value if it was removed/commented-out or an
    explicit change request to a different value.

Personally, I'm very interested in having both.  I'm about 90% sure both
were discussed previously on hackers and that the general consensus was
that both were good.  It's possible the second point wasn't noticed by
everyone involved though.  Of course, I might be misunderstanding what
Joachim was referring to also.

    Thanks,

        Stephen

Am Montag, 24. Juli 2006 16:55 schrieb Stephen Frost:
> #2: That variable can *not* be changed by a reload.
>     Notice-level message is sent to the log notifying the admin that the
>     change requested could not be performed.

This already happens.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

On Mon, Jul 24, 2006 at 07:09:17PM +0200, Peter Eisentraut wrote:
> Am Montag, 24. Juli 2006 16:55 schrieb Stephen Frost:
> > #2: That variable can *not* be changed by a reload.
> >     Notice-level message is sent to the log notifying the admin that the
> >     change requested could not be performed.

> This already happens.

Not if the option gets commented/deleted, i.e.:

shared_buffers = 8000
START
#shared_buffers = 8000
HUP

This does not issue a message at the moment.


Joachim

On Mon, Jul 24, 2006 at 10:55:47AM -0400, Stephen Frost wrote:
> #2: That variable can *not* be changed by a reload.
>     Notice-level message is sent to the log notifying the admin that the
>     change requested could not be performed.  This change could be
>     either a revert to reset-value if it was removed/commented-out or an
>     explicit change request to a different value.

Right. And what I am voting for is to not only issue such a message once but
every time a SIGHUP is received as long as the actively-used value differs
from the value in the configuration file. One of the reasons for having this
fall-back-to-default-value stuff is to make sure that an admin can restart a
server and be sure that it will behave in the same way as when it was
shut down.

Moreover it's just clearer to send the notice message every time a SIGHUP is
received since every reload is the admin's request to apply all of the
values in the configuration file independently of what has happened in the
past.


Joachim

Joachim Wieland wrote:
> On Mon, Jul 24, 2006 at 07:09:17PM +0200, Peter Eisentraut wrote:
> > Am Montag, 24. Juli 2006 16:55 schrieb Stephen Frost:
> > > #2: That variable can *not* be changed by a reload.
> > >     Notice-level message is sent to the log notifying the admin
> > > that the change requested could not be performed.
> >
> > This already happens.
>
> Not if the option gets commented/deleted, i.e.:
>
> shared_buffers = 8000
> START
> #shared_buffers = 8000
> HUP
>
> This does not issue a message at the moment.

Because at the moment, the above does not change the value of
shared_buffers.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/