Re: Allow commenting of variables in postgresql.conf to - try 4

From: Joachim Wieland <joe(at)mcknight(dot)de>
To: Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM>
Cc: pgsql-patches(at)postgresql(dot)org
Subject: Re: Allow commenting of variables in postgresql.conf to - try 4
Date: 2006-07-24 11:30:36
Message-ID: 20060724113036.GA4693@mcknight.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Zdenek,

On Fri, Jul 14, 2006 at 12:17:55AM +0200, Zdenek Kotala wrote:
> There is last version of patch with following changes/improvements:

> 1) I divide set_config_option to more smaller functions without backside
> effect.

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. That way, at every moment you can see if the active
values coincide with the configuration file by sending a SIGHUP and if there
are no such messages the admin can stop and restart the server and be sure
that the settings will be the same after a restart.

While testing, I specified a bunch of test cases that I attach below.

I also renamed the GUC_JUST_RELOAD to GUC_IN_CONFFILE because I did not
really understand what GUC_JUST_RELOAD should mean. GUC_IN_CONFFILE means
that the variable does show up in the configuration file and is active
there, i.e. is not commented.

Please check my changes, I'm pretty sure it can be cleaned up further.

Joachim

Test cases for "guc falls back to default":

guc_context <= PGC_POSTMASTER (shared_buffers is an example, Default: 1000)

Commented value gets un-commented (value != default)
=> message every time a sighup is received

Example:
#shared_buffers = 3301
START
shared_buffers = 3301
HUP

Output:
LOG: parameter "shared_buffers" cannot be changed after server start;
configuration file change ignored

Value gets changed (to != initial).
=> message every time a sighup is received

Example:
shared_buffers = 3301
START
shared_buffers = 3302
HUP

Output:
LOG: parameter "max_prepared_transactions" cannot be changed after
server start; configuration file change ignored

Value gets commented (initial != default).
=> message every time a sighup is received

Example:
shared_buffers = 3301
START
#shared_buffers = 3301
HUP

Output:
LOG: parameter "max_prepared_transactions" cannot be changed
(commented) after server start; configuration file change ignored

Commented value (not applied) gets changed back to initial setting:
=> no more messages after SIGHUP

Example:
shared_buffers = 3301
START
#shared_buffers = 3301
HUP (value does not get applied)
shared_buffers = 3301
HUP

Output:
None

Commented value (not applied) gets changed to != initial:
=> message every time a SIGHUP is received

Example:
shared_buffers = 3301
START
#shared_buffers = 3301
HUP
shared_buffers = 3302
HUP

Output:
LOG: parameter "shared_buffers" cannot be changed after server start;
configuration file change ignored

guc_context <= PGC_SIGHUP set (fsync is an example, Default: true)

Value (== default) gets commented
=> nothing happens

Example:
fsync = true
START
#fsync = true
HUP

Output:
None

Value (!= default) gets commented
=> falls back to default on first HUP that is received)

Example:
fsync = false
START
fsync = true
HUP
(subsequent HUPs do not show output anymore)

Output:
LOG: configuration option fsync falls back to default value

Commented value gets un-commented (value != default)

Example:
#fsync = false
START
fsync = false
HUP

Output:
None

Commented value gets un-commented (value == default)

Example:
#fsync = true
START
fsync = true
HUP

Output:
None

Attachment Content-Type Size
pg_guc_default.rev.1.diff text/plain 39.0 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2006-07-24 11:39:44 Re: Adding a pgbench run to buildfarm
Previous Message Joerg Hessdoerfer 2006-07-24 10:04:10 Re: Transaction Speed and real time database

Browse pgsql-patches by date

  From Date Subject
Next Message Sergey E. Koposov 2006-07-24 11:47:41 Re: patch implementing the multi-argument aggregates (SOC
Previous Message Zdenek Kotala 2006-07-24 11:00:16 Re: Mark change-on-restart-only values in postgresql.conf