Thread: Logging configuration changes
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@gmx.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@gmx.net> writes:
> 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.
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.
Attachment
(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@gmx.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
Attachment
On Wed, Sep 16, 2009 at 12:24 AM, Abhijit Menon-Sen <ams@toroid.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@systemguards.com.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
Attachment
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.