Re: Logging configuration changes [REVIEW]

From: Abhijit Menon-Sen <ams(at)toroid(dot)org>
To: pgsql-hackers(at)postgresql(dot)org
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>
Subject: Re: Logging configuration changes [REVIEW]
Date: 2009-09-16 05:24:14
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

(This is my review of the small patch Peter posted on 2009-08-29. See
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:

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 Content-Type Size
log-parameter-changes.diff text/x-diff 1.7 KB
revise-293c81.diff text/x-diff 1.7 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Davis 2009-09-16 05:55:29 Re: opportunistic tuple freezing
Previous Message Itagaki Takahiro 2009-09-16 04:47:19 Re: FDW-based dblink (WIP)