Re: Logging configuration changes [REVIEW]

On occasion, I would have found it useful if a SIGHUP didn't only log *that*
it reloaded the configuration files, but also logged *what* had changed
(postgresql.conf changes in particular, not so much interested in
pg_hba.conf). Especially in light of the common mistake of forgetting to
uncomment a changed value, this would appear to be useful.

Comments?

On Sun, Jul 12, 2009 at 3:55 PM, Peter Eisentraut<peter_e(at)gmx(dot)net> wrote:
> On occasion, I would have found it useful if a SIGHUP didn't only log *that*
> it reloaded the configuration files, but also logged *what* had changed
> (postgresql.conf changes in particular, not so much interested in
> pg_hba.conf).  Especially in light of the common mistake of forgetting to
> uncomment a changed value, this would appear to be useful.
>
> Comments?

Sounds neat.

...Robert

On sön, 2009-07-12 at 22:55 +0300, Peter Eisentraut wrote:
> On occasion, I would have found it useful if a SIGHUP didn't only log *that*
> it reloaded the configuration files, but also logged *what* had changed
> (postgresql.conf changes in particular, not so much interested in
> pg_hba.conf). Especially in light of the common mistake of forgetting to
> uncomment a changed value, this would appear to be useful.

Looked into this, looks trivial, except that this would log *all*
parameters that were set as a result of a reload, instead of only the
ones that changed. We don't have the information of what it was
previously readily available.

I think it would still be useful that way, but some people might find it
annoying.

Comments?

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> On sn, 2009-07-12 at 22:55 +0300, Peter Eisentraut wrote:
>> On occasion, I would have found it useful if a SIGHUP didn't only log *that*
>> it reloaded the configuration files, but also logged *what* had changed
>> (postgresql.conf changes in particular, not so much interested in
>> pg_hba.conf). Especially in light of the common mistake of forgetting to
>> uncomment a changed value, this would appear to be useful.

> Looked into this, looks trivial, except that this would log *all*
> parameters that were set as a result of a reload, instead of only the
> ones that changed. We don't have the information of what it was
> previously readily available.

> I think it would still be useful that way, but some people might find it
> annoying.

Seems to me it would be too chatty to be useful, at least for people who
set more than one or two things in postgresql.conf. Would it be that
hard to track which values actually changed? Without having looked at
the code, I'm thinking that much of the infrastructure must be there
already now that we have support for undoing commented-out settings.

regards, tom lane

On ons, 2009-08-26 at 22:13 -0400, Tom Lane wrote:
> Seems to me it would be too chatty to be useful, at least for people who
> set more than one or two things in postgresql.conf. Would it be that
> hard to track which values actually changed? Without having looked at
> the code, I'm thinking that much of the infrastructure must be there
> already now that we have support for undoing commented-out settings.

Found an easy solution; see attached patch.

On a related note, I suggest reverting or revising this logging change:
http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=293c816e4aad8e760bcb4eaba0aa16da0ccd2d04
Putting the reason for an error or warning into the detail part is not
acceptable style, IMO.

(This is my review of the small patch Peter posted on 2009-08-29. See
http://archives.postgresql.org/message-id/1251495487.18151.12.camel@vanquo.pezone.net
for the original message.)

At 2009-08-29 00:38:07 +0300, peter_e(at)gmx(dot)net wrote:
>
> Found an easy solution; see attached patch.

Neat. The patch (a) applies to HEAD and builds correctly, (b) does what
it's supposed to, i.e. report parameters whose value has been changed or
reset to the default, and (c) seems sensible.

I can't help but think that it would be nice to report the default value
of a parameter that is reset (i.e. "parameter $x reset to default value
$y"). The first attached patch does this by calling GetConfigOption()
after the value has been reset by set_config_option(). It also skips
the report if the earlier value was the same as the default.

> On a related note, I suggest reverting or revising this logging change:
> http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=293c816e4aad8e760bcb4eaba0aa16da0ccd2d04

FWIW, I agree about this too.

I would suggest changing the errmsg to just "Parameter \"%s\" cannot be
changed without restarting the server". I have attached a second patch
to do this.

LOG: received SIGHUP, reloading configuration files
LOG: parameter "log_connections" reset to default value "off"
LOG: parameter "log_disconnections" reset to default value "off"
LOG: Parameter "max_connections" cannot be changed without restarting the server
LOG: parameter "log_checkpoints" changed to "on"

-- ams

On Wed, Sep 16, 2009 at 12:24 AM, Abhijit Menon-Sen <ams(at)toroid(dot)org> wrote:
>
> LOG:  received SIGHUP, reloading configuration files
> LOG:  parameter "log_connections" reset to default value "off"
> LOG:  parameter "log_disconnections" reset to default value "off"
> LOG:  Parameter "max_connections" cannot be changed without restarting the server
> LOG:  parameter "log_checkpoints" changed to "on"
>

ok, maybe this is not the most brilliant observation but someone has
to say it... keep the same case in the word "parameter" ;)

--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59387171157

At 2009-09-16 01:18:10 -0500, jcasanov(at)systemguards(dot)com(dot)ec wrote:
>
> ok, maybe this is not the most brilliant observation but someone has
> to say it... keep the same case in the word "parameter" ;)

Oops, thanks. Re²vised patch attached.

-- ams

On ons, 2009-09-16 at 10:54 +0530, Abhijit Menon-Sen wrote:
> I can't help but think that it would be nice to report the default value
> of a parameter that is reset (i.e. "parameter $x reset to default value
> $y"). The first attached patch does this by calling GetConfigOption()
> after the value has been reset by set_config_option(). It also skips
> the report if the earlier value was the same as the default.

I have applied the rest, but the problem with this change is that it
logs the values without units. I'm not sure that we want to expose
that.