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

2006-07-24 Thread Joachim Wieland
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

diff -cr cvs/pgsql/src/backend/utils/misc/guc.c 
cvs.build/pgsql/src/backend/utils/misc/guc.c
*** cvs/pgsql/src/backend/utils/misc/guc.c  2006-07-14 22:19:46.0 
+0200
--- cvs.build/pgsql/src/backend/utils/misc/guc.c2006-07-24 
12:22:55.0 +0200
***
*** 2667,2705 
struct config_bool *conf = (struct 
config_bool *) gconf;
  
if (conf-assign_hook)
!   if (!(*conf-assign_hook) 
(conf-reset_val, true,

   PGC_S_DEFAULT))
elog(FATAL, failed to 
initialize %s to %d,
!
conf-gen.name, (int) conf-reset_val);
!   *conf-variable = conf-reset_val;
break;
}

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

2006-07-24 Thread Tom Lane
Joachim Wieland [EMAIL PROTECTED] writes:
 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.

Notice message?  Where did that come from?  The behavior I thought
people were after was just that variables previously defined by the file
would revert to reset values if not any longer defined by the file.

From a reviewer's point of view, it'd be nice if the patch did not
contain so many useless changes of whitespace.

regards, tom lane

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match


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

2006-07-24 Thread Peter Eisentraut
Am Montag, 24. Juli 2006 16:55 schrieb Stephen Frost:
 #2: That variable can *not* be changed by a reload.
 Notice-level message is sent to the log notifying the admin that the
   change requested could not be performed.

This already happens.

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly


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

2006-07-24 Thread Joachim Wieland
On Mon, Jul 24, 2006 at 10:55:47AM -0400, Stephen Frost wrote:
 #2: That variable can *not* be changed by a reload.
 Notice-level message is sent to the log notifying the admin that the
   change requested could not be performed.  This change could be
   either a revert to reset-value if it was removed/commented-out or an
   explicit change request to a different value.

Right. And what I am voting for is to not only issue such a message once but
every time a SIGHUP is received as long as the actively-used value differs
from the value in the configuration file. One of the reasons for having this
fall-back-to-default-value stuff is to make sure that an admin can restart a
server and be sure that it will behave in the same way as when it was
shut down.

Moreover it's just clearer to send the notice message every time a SIGHUP is
received since every reload is the admin's request to apply all of the
values in the configuration file independently of what has happened in the
past.


Joachim


---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq


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

2006-07-24 Thread Peter Eisentraut
Joachim Wieland wrote:
 On Mon, Jul 24, 2006 at 07:09:17PM +0200, Peter Eisentraut wrote:
  Am Montag, 24. Juli 2006 16:55 schrieb Stephen Frost:
   #2: That variable can *not* be changed by a reload.
   Notice-level message is sent to the log notifying the admin
   that the change requested could not be performed.
 
  This already happens.

 Not if the option gets commented/deleted, i.e.:

 shared_buffers = 8000
 START
 #shared_buffers = 8000
 HUP

 This does not issue a message at the moment.

Because at the moment, the above does not change the value of 
shared_buffers.

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/

---(end of broadcast)---
TIP 6: explain analyze is your friend