FAQ
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?

Search Discussions

  • Robert Haas at Jul 12, 2009 at 9:16 pm

    On Sun, Jul 12, 2009 at 3:55 PM, Peter Eisentrautwrote:
    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
  • Peter Eisentraut at Aug 26, 2009 at 11:32 pm

    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?
  • Tom Lane at Aug 27, 2009 at 2:13 am

    Peter Eisentraut 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
  • Peter Eisentraut at Aug 28, 2009 at 9:38 pm

    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.
  • Abhijit Menon-Sen at Sep 16, 2009 at 5:56 am
    (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
  • Jaime Casanova at Sep 16, 2009 at 6:18 am

    On Wed, Sep 16, 2009 at 12:24 AM, Abhijit Menon-Sen 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
  • Abhijit Menon-Sen at Sep 16, 2009 at 6:27 am

    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
  • Peter Eisentraut at Sep 17, 2009 at 9:39 pm

    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.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedJul 12, '09 at 7:55p
activeSep 17, '09 at 9:39p
posts9
users5
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2021 Grokbase