Re: [PATCHES] Allow commenting of variables in postgresql.conf to -
Peter, What is the status of this patch now? I read that two bugs has been fixed in this patch and now it is waiting for new review. Is there something what I can/must do? Zdenek Peter Eisentraut wrote: Zdenek Kotala wrote: OK. I split patch to two parts. Part one is refactoring of set_config_options function. Part two implements feature Allow commenting of variables in postgresql.conf to restore them to defaults. I'm having trouble wrapping my head around a code refactoring which actually makes the code significantly *longer*. The only interface change I could detect is the introduction of a function verify_config_option(), which should just be a small variation on set_config_option() as it currently exists. I'm also about a relive a personal trauma if I see error messages like this: errmsg(configuration file is invalid) I just had to deal with an unnamed product where this was all you got! Please, explain again what this refactoring is supposed to achieve. The second part of your patch actually looks pretty reasonable and does not appear to require the refactoring. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] Allow commenting of variables in
Zdenek Kotala wrote: Peter, What is the status of this patch now? I read that two bugs has been fixed in this patch and now it is waiting for new review. Is there something what I can/must do? The patch was applied, fixed, and fixed again, then reverted. It will sit until just before beta, where it will be applied or a vote will be taken on whether to apply it. There is nothing more you have to do on it. I think the fixes just scared some folks so there is hope more review might happen before beta. --- Zdenek Peter Eisentraut wrote: Zdenek Kotala wrote: OK. I split patch to two parts. Part one is refactoring of set_config_options function. Part two implements feature Allow commenting of variables in postgresql.conf to restore them to defaults. I'm having trouble wrapping my head around a code refactoring which actually makes the code significantly *longer*. The only interface change I could detect is the introduction of a function verify_config_option(), which should just be a small variation on set_config_option() as it currently exists. I'm also about a relive a personal trauma if I see error messages like this: errmsg(configuration file is invalid) I just had to deal with an unnamed product where this was all you got! Please, explain again what this refactoring is supposed to achieve. The second part of your patch actually looks pretty reasonable and does not appear to require the refactoring. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] Allow commenting of variables in postgresql.conf to -
Am Mittwoch, 23. August 2006 14:44 schrieb Zdenek Kotala: What is the status of this patch now? I read that two bugs has been fixed in this patch and now it is waiting for new review. Is there something what I can/must do? As I said previously, if you are refactoring code to make it longer, then I don't believe in the merit of the patch. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] Allow commenting of variables in
Peter Eisentraut wrote: Am Mittwoch, 23. August 2006 14:44 schrieb Zdenek Kotala: What is the status of this patch now? I read that two bugs has been fixed in this patch and now it is waiting for new review. Is there something what I can/must do? As I said previously, if you are refactoring code to make it longer, then I don't believe in the merit of the patch. The refactoring was to fix problems in incorrect parsing of the config file. I believe the example was: http://archives.postgresql.org/pgsql-committers/2006-08/msg00245.php -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(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 -
Patch applied. Thanks. --- Zdenek Kotala wrote: Peter Eisentraut wrote: The way I see it, combining a feature change with a code refactoring and random white space changes is a pretty optimal way to get your patch rejected. Please submit patches for these items separately. OK. I split patch to two parts. Part one is refactoring of set_config_options function. Part two implements feature Allow commenting of variables in postgresql.conf to restore them to defaults. Zdenek -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] Allow commenting of variables in postgresql.conf to -
Peter Eisentraut napsal(a): Zdenek Kotala wrote: OK. I split patch to two parts. Part one is refactoring of set_config_options function. Part two implements feature Allow commenting of variables in postgresql.conf to restore them to defaults. I'm having trouble wrapping my head around a code refactoring which actually makes the code significantly *longer*. The only interface change I could detect is the introduction of a function verify_config_option(), which should just be a small variation on set_config_option() as it currently exists. The main reason for refactoring was that set_config_option() was too overloaded function and its behavior did not consistent. Old version of set_config_function hides some messages. For example if you type: tcp_port = 5432.1 then old implementation ignore this error without any message to log file in the signal context (configuration reload). Main problem was that semantic analysis of postgresql.conf is not perform in the ProcessConfigFile function, but in the set_config_options *after* context check. This skipped check for variables with PG_POSTMASTER context. There was request from Joachim Wieland to add more messages about ignored changes in the config file as well. I'm also about a relive a personal trauma if I see error messages like this: errmsg(configuration file is invalid) I just had to deal with an unnamed product where this was all you got! Do you have any idea for better message? This message is last one during parsing process. What is wrong is logged before this message. Zdenek ---(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 -
Zdenek Kotala wrote: OK. I split patch to two parts. Part one is refactoring of set_config_options function. Part two implements feature Allow commenting of variables in postgresql.conf to restore them to defaults. I'm having trouble wrapping my head around a code refactoring which actually makes the code significantly *longer*. The only interface change I could detect is the introduction of a function verify_config_option(), which should just be a small variation on set_config_option() as it currently exists. I'm also about a relive a personal trauma if I see error messages like this: errmsg(configuration file is invalid) I just had to deal with an unnamed product where this was all you got! Please, explain again what this refactoring is supposed to achieve. The second part of your patch actually looks pretty reasonable and does not appear to require the refactoring. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(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 -
Peter Eisentraut wrote:
The way I see it, combining a feature change with a code refactoring and
random white space changes is a pretty optimal way to get your patch
rejected. Please submit patches for these items separately.
OK. I split patch to two parts. Part one is refactoring of
set_config_options function. Part two implements feature Allow
commenting of variables in postgresql.conf to restore them to defaults.
Zdenek
diff -r -c pgsql/src/backend/utils/misc/guc-file.l pgsql_1/src/backend/utils/misc/guc-file.l
*** pgsql/src/backend/utils/misc/guc-file.l Thu Jul 27 10:30:41 2006
--- pgsql_1/src/backend/utils/misc/guc-file.l Wed Aug 2 13:35:27 2006
***
*** 50,56
static bool ParseConfigFile(const char *config_file, const char *calling_file,
int depth, GucContext context, int elevel,
struct name_value_pair **head_p,
! struct name_value_pair **tail_p);
static void free_name_value_list(struct name_value_pair * list);
static char *GUC_scanstr(const char *s);
--- 50,57
static bool ParseConfigFile(const char *config_file, const char *calling_file,
int depth, GucContext context, int elevel,
struct name_value_pair **head_p,
! struct name_value_pair **tail_p,
! int *varcount);
static void free_name_value_list(struct name_value_pair * list);
static char *GUC_scanstr(const char *s);
***
*** 114,121
void
ProcessConfigFile(GucContext context)
{
! int elevel;
struct name_value_pair *item, *head, *tail;
Assert(context == PGC_POSTMASTER || context == PGC_SIGHUP);
--- 115,124
void
ProcessConfigFile(GucContext context)
{
! int elevel, i;
struct name_value_pair *item, *head, *tail;
+ bool *apply_list = NULL;
+ int varcount = 0;
Assert(context == PGC_POSTMASTER || context == PGC_SIGHUP);
***
*** 134,158
if (!ParseConfigFile(ConfigFileName, NULL,
0, context, elevel,
! head, tail))
goto cleanup_list;
/* Check if all options are valid */
! for (item = head; item; item = item-next)
{
! if (!set_config_option(item-name, item-value, context,
! PGC_S_FILE, false, false))
goto cleanup_list;
}
/* If we got here all the options checked out okay, so apply them. */
! for (item = head; item; item = item-next)
! {
! set_config_option(item-name, item-value, context,
! PGC_S_FILE, false, true);
! }
! cleanup_list:
free_name_value_list(head);
}
--- 137,192
if (!ParseConfigFile(ConfigFileName, NULL,
0, context, elevel,
! head, tail, varcount))
goto cleanup_list;
+ /* Can we allocate memory here, what about leaving here prematurely? */
+ apply_list = (bool *) palloc(sizeof(bool) * varcount);
+
/* Check if all options are valid */
! for (item = head, i = 0; item; item = item-next, i++)
{
! bool isEqual, isContextOk;
!
! if (!verify_config_option(item-name, item-value, context,
! PGC_S_FILE, isEqual, isContextOk))
! {
! ereport(elevel,
! (errcode(ERRCODE_CANT_CHANGE_RUNTIME_PARAM),
! errmsg(configuration file is invalid)));
goto cleanup_list;
+ }
+
+ if( isContextOk == false )
+ {
+ apply_list[i] = false;
+ if( context == PGC_SIGHUP )
+ {
+ if ( isEqual == false )
+ ereport(elevel,
+ (errcode(ERRCODE_CANT_CHANGE_RUNTIME_PARAM),
+ errmsg(parameter \%s\ cannot be changed after server start; configuration file change ignored,
+ item-name)));
+ }
+ else
+ /* if it is boot phase, context must be valid for all
+ * configuration item. */
+ goto cleanup_list;
+ }
+ else
+ apply_list[i] = true;
}
/* If we got here all the options checked out okay, so apply them. */
! for (item = head, i = 0; item; item = item-next, i++)
! if (apply_list[i])
! set_config_option(item-name, item-value, context,
! PGC_S_FILE, false, true);
!
! cleanup_list:
! if (apply_list)
! pfree(apply_list);
free_name_value_list(head);
}
***
*** 189,201
ParseConfigFile(const char *config_file, const char *calling_file,
int depth, GucContext context, int elevel,
struct name_value_pair **head_p,
! struct name_value_pair **tail_p)
{
! bool OK = true;
! char abs_path[MAXPGPATH];
! FILE *fp;
YY_BUFFER_STATE lex_buffer;
! int token;
/*
* Reject too-deep include nesting depth. This is just a safety check
--- 223,236
ParseConfigFile(const char *config_file, const char *calling_file,
int depth, GucContext context, int elevel,
struct name_value_pair **head_p,
! struct name_value_pair **tail_p,
! int *varcount)
{
! bool OK = true;
! char abs_path[MAXPGPATH];
! FILE *fp;
YY_BUFFER_STATE lex_buffer;
! inttoken;
/*
* Reject too-deep include nesting depth. This is just a safety check
***
*** 289,295
Re: [PATCHES] Allow commenting of variables in postgresql.conf to -
Zdenek Kotala wrote: I performed some cleanup in my code as well. I reduced some conditions, which cannot occur and fixed context validation in the set_config_options function. I hope that It is final version of our patch. The way I see it, combining a feature change with a code refactoring and random white space changes is a pretty optimal way to get your patch rejected. Please submit patches for these items separately. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] Allow commenting of variables in postgresql.conf to -
Joachim,
I checked your improvement and fix some problem with following scenario:
shared_buffers = 3301
START
share_buffers = 333.39
HUP
share_buffers requires integer value. Skip configuration file
#share_buffers = 3301
HUP
silent - no message
I performed some cleanup in my code as well. I reduced some conditions,
which cannot occur and fixed context validation in the
set_config_options function. I hope that It is final version of our patch.
Thanks for cooperation
Zdenek
Index: src/backend/utils/misc/guc-file.l
===
RCS file: /projects/cvsroot/pgsql/src/backend/utils/misc/guc-file.l,v
retrieving revision 1.37
diff -c -r1.37 guc-file.l
*** src/backend/utils/misc/guc-file.l 7 Mar 2006 01:03:12 - 1.37
--- src/backend/utils/misc/guc-file.l 27 Jul 2006 14:07:46 -
***
*** 50,56
static bool ParseConfigFile(const char *config_file, const char *calling_file,
int depth, GucContext context, int elevel,
struct name_value_pair **head_p,
! struct name_value_pair **tail_p);
static void free_name_value_list(struct name_value_pair * list);
static char *GUC_scanstr(const char *s);
--- 50,57
static bool ParseConfigFile(const char *config_file, const char *calling_file,
int depth, GucContext context, int elevel,
struct name_value_pair **head_p,
! struct name_value_pair **tail_p,
! int *varcount);
static void free_name_value_list(struct name_value_pair * list);
static char *GUC_scanstr(const char *s);
***
*** 112,119
void
ProcessConfigFile(GucContext context)
{
! int elevel;
struct name_value_pair *item, *head, *tail;
Assert(context == PGC_POSTMASTER || context == PGC_SIGHUP);
--- 113,123
void
ProcessConfigFile(GucContext context)
{
! int elevel, i;
struct name_value_pair *item, *head, *tail;
+ char *env;
+ bool *apply_list = NULL;
+ int varcount = 0;
Assert(context == PGC_POSTMASTER || context == PGC_SIGHUP);
***
*** 132,156
if (!ParseConfigFile(ConfigFileName, NULL,
0, context, elevel,
! head, tail))
goto cleanup_list;
/* Check if all options are valid */
! for (item = head; item; item = item-next)
{
! if (!set_config_option(item-name, item-value, context,
! PGC_S_FILE, false, false))
goto cleanup_list;
}
/* If we got here all the options checked out okay, so apply them. */
! for (item = head; item; item = item-next)
{
! set_config_option(item-name, item-value, context,
! PGC_S_FILE, false, true);
}
! cleanup_list:
free_name_value_list(head);
}
--- 136,243
if (!ParseConfigFile(ConfigFileName, NULL,
0, context, elevel,
! head, tail, varcount))
goto cleanup_list;
+ /* Can we allocate memory here, what about leaving here prematurely? */
+ apply_list = (bool *) palloc(sizeof(bool) * varcount);
+
/* Check if all options are valid */
! for (item = head, i = 0; item; item = item-next, i++)
{
! bool isEqual, isContextOk;
!
! if (!verify_config_option(item-name, item-value, context,
! PGC_S_FILE, isEqual, isContextOk))
! {
! ereport(elevel,
! (errcode(ERRCODE_CANT_CHANGE_RUNTIME_PARAM),
! errmsg(configuration file is invalid)));
goto cleanup_list;
+ }
+
+ if( isContextOk == false )
+ {
+ apply_list[i] = false;
+ if( context == PGC_SIGHUP )
+ {
+ if ( isEqual == false )
+ ereport(elevel,
+ (errcode(ERRCODE_CANT_CHANGE_RUNTIME_PARAM),
+ errmsg(parameter \%s\ cannot be changed after server start; configuration file change ignored,
+ item-name)));
+ }
+ else
+ /* if it is boot phase, context must be valid for all
+ * configuration item. */
+ goto cleanup_list;
+ }
+ else
+ apply_list[i] = true;
}
/* If we got here all the options checked out okay, so apply them. */
! for (item = head, i = 0; item; item = item-next, i++)
! if (apply_list[i])
! set_config_option(item-name, item-value, context,
! PGC_S_FILE, false, true);
!
! if( context == PGC_SIGHUP)
{
! /*
! * Revert all untouched options with reset source PGC_S_FILE to
! * default/boot value.
! */
! for (i = 0; i num_guc_variables; i++)
! {
! struct config_generic *gconf = guc_variables[i];
! if ( gconf-reset_source == PGC_S_FILE
! !(gconf-status GUC_IN_CONFFILE) )
! {
! if ( gconf-context == PGC_BACKEND IsUnderPostmaster)
! ; /* Be silent. Does any body want message from each session? */
! else if (gconf-context == PGC_POSTMASTER)
! ereport(elevel,
! (errcode(ERRCODE_CANT_CHANGE_RUNTIME_PARAM),
! errmsg(parameter \%s\ cannot be changed (commented) after server start; configuration file change ignored,
! gconf-name)));
! else if(set_config_option(gconf-name,
Re: [PATCHES] Allow commenting of variables in postgresql.conf to -
Joachim Wieland wrote: Zdenek, 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. It would be nice to have this like regression test. I'm still thinking how to realize it. There is problem how to change postgresql.conf without backside effect on other test and for all platform. 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. Yes, you have right, JUST_RELOAD is not much clear. I look that you little bit changed function of this flag to. I think it is better and more clear. However, I have some doubt that in the some special case - SET/RESET usage in transaction - should generate some wrong output. I'm working on some deep analyze and test case. Please check my changes, I'm pretty sure it can be cleaned up further. Thanks for your improvement. Zdenek ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Allow commenting of variables in postgresql.conf to - try 4
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
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
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
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
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
Re: [PATCHES] Allow commenting of variables in postgresql.conf to -
There is last version of patch with following changes/improvements:
1) I divide set_config_option to more smaller functions without backside
effect.
2) Behavior of reconfiguration is same in SIG_HUP context (exclude
elevel). All errors are reported and full validity of file is checked too.
Zdenek
Index: src/backend/utils/misc/guc-file.l
===
RCS file: /projects/cvsroot/pgsql/src/backend/utils/misc/guc-file.l,v
retrieving revision 1.37
diff -c -r1.37 guc-file.l
*** src/backend/utils/misc/guc-file.l 7 Mar 2006 01:03:12 - 1.37
--- src/backend/utils/misc/guc-file.l 13 Jul 2006 21:55:28 -
***
*** 112,119
void
ProcessConfigFile(GucContext context)
{
! int elevel;
struct name_value_pair *item, *head, *tail;
Assert(context == PGC_POSTMASTER || context == PGC_SIGHUP);
--- 112,120
void
ProcessConfigFile(GucContext context)
{
! int elevel, i;
struct name_value_pair *item, *head, *tail;
+ char *env;
Assert(context == PGC_POSTMASTER || context == PGC_SIGHUP);
***
*** 137,146
/* Check if all options are valid */
for (item = head; item; item = item-next)
! {
! if (!set_config_option(item-name, item-value, context,
! PGC_S_FILE, false, false))
goto cleanup_list;
}
/* If we got here all the options checked out okay, so apply them. */
--- 138,173
/* Check if all options are valid */
for (item = head; item; item = item-next)
! {
! bool isEqual, isContextOk;
!
! if (!verify_config_option(item-name, item-value, context,
! PGC_S_FILE, isEqual, isContextOk))
! {
! ereport(elevel,
! (errcode(ERRCODE_CANT_CHANGE_RUNTIME_PARAM),
! errmsg(configuration file is invalid)));
goto cleanup_list;
+ }
+
+ if( isContextOk == false )
+ {
+ if( context == PGC_SIGHUP )
+ {
+ if ( isEqual == false )
+ {
+ ereport(elevel,
+ (errcode(ERRCODE_CANT_CHANGE_RUNTIME_PARAM),
+ errmsg(parameter \%s\ cannot be changed after server start; configuration file change ignored,
+ item-name)));
+ }
+ }
+ else
+ {
+ // if it is boot phase loading context must be valid for all configuration item.
+ goto cleanup_list;
+ }
+ }
}
/* If we got here all the options checked out okay, so apply them. */
***
*** 150,155
--- 177,233
PGC_S_FILE, false, true);
}
+ if( context == PGC_SIGHUP)
+ {
+ /* Revert all untouched options with reset source PGC_S_FILE to
+ * default/boot value.
+ */
+ for (i = 0; i num_guc_variables; i++)
+ {
+ struct config_generic *gconf = guc_variables[i];
+ if ( gconf-context != PGC_INTERNAL gconf-context != PGC_POSTMASTER
+ !( gconf-context == PGC_BACKEND IsUnderPostmaster)
+ (gconf-reset_source == PGC_S_FILE) ( (gconf-status GUC_JUST_RELOAD) == 0) )
+ {
+ if( set_config_option(gconf-name, NULL, context,
+ PGC_S_FILE, false, true) )
+ {
+ GucStack *stack;
+ /* set correctly source */
+ gconf-reset_source = PGC_S_DEFAULT;
+ for (stack = gconf-stack; stack; stack = stack-prev)
+ {
+ if (stack-source == PGC_S_FILE)
+ {
+ stack-source = PGC_S_DEFAULT;
+ }
+ }
+
+ ereport(elevel,
+ (errcode(ERRCODE_SUCCESSFUL_COMPLETION),
+ errmsg(configuration option %s has been revert to the boot value, gconf-name)));
+ }
+ }
+ gconf-status = ~GUC_JUST_RELOAD;
+ }
+
+ /* Revert to environment variable. PGPORT is ignored, because it cannot be
+ * set in running state.
+ */
+ env = getenv(PGDATESTYLE);
+ if (env != NULL)
+ {
+ set_config_option(datestyle, env, context,
+ PGC_S_ENV_VAR, false, true);
+ }
+
+ env = getenv(PGCLIENTENCODING);
+ if (env != NULL)
+ {
+ set_config_option(client_encoding, env, context,
+ PGC_S_ENV_VAR, false, true);
+ }
+ }
cleanup_list:
free_name_value_list(head);
}
Index: src/backend/utils/misc/guc.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/utils/misc/guc.c,v
retrieving revision 1.319
diff -c -r1.319 guc.c
*** src/backend/utils/misc/guc.c 11 May 2006 19:15:35 - 1.319
--- src/backend/utils/misc/guc.c 13 Jul 2006 21:55:28 -
***
*** 2648,2686
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;
}
case PGC_INT:
{
struct config_int *conf = (struct config_int *) gconf;
! Assert(conf-reset_val = conf-min);
! Assert(conf-reset_val = conf-max);
if
Re: [PATCHES] Allow commenting of variables in postgresql.conf to -
Joachim Wieland wrote: Still it does not what I think it should do. I might have been unclear before. If you put a comment in front of a PGC_POSTMASTER variable (and if its value differs from the default) then this should be treated as if the variable got changed and it should emmit a warning varname can only be changed on server start or similar. This warning should be kept for every other SIGHUP that gets sent just like it is done already when you change the value (but do not comment the variable). Thanks for explanation. I overlooked this variant. When I analyzed set_config_option I found some other bugs or strange things: 1) Try to change internal variable in the config file is silently ignored during reconfiguration. 2) GUC_DISALLOW_IN_FILE flag is ignored during configuration file parsing. 3) If option is PGC_POSTMASTER type and value is not syntax valid, It only generates warning message that value cannot be change and file parsing continue. Could some one validates my findings? I think that set_config_options is too huge and very overloaded. By my opinion divide to small functions is necessary to fix this behavior and its increase maintainability. Zdenek ---(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 -
Zdenek Kotala [EMAIL PROTECTED] writes: 2) GUC_DISALLOW_IN_FILE flag is ignored during configuration file parsing. Yeah, that's not enforced at the moment, it's just documentation. Most of the variables that are marked that way have other defenses against being changed from the file, so I'm not sure that it's real important to have a specific check for it. 1) Try to change internal variable in the config file is silently ignored during reconfiguration. Note that there are two separate behaviors: during postmaster startup, errors in the config file are cause for aborting. During SIGHUP reread, errors in the config file may NOT cause an abort. This is intentional. The postmaster (and only the postmaster, not the N backends that are also rereading the file) is supposed to emit a log message about any problems, but it mustn't error out. I think that set_config_options is too huge and very overloaded. By my opinion divide to small functions is necessary to fix this behavior and its increase maintainability. Feel free to propose a suitable refactoring. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] Allow commenting of variables in postgresql.conf to - try3
Zdenek, On Thu, Jun 01, 2006 at 04:56:10PM +0200, Zdenek Kotala wrote: Thanks, You have right. It is problem with silent skip some option in set_config_option function when PGC_SIGHUP is running context. I fix it and I attach third version of patch. Still it does not what I think it should do. I might have been unclear before. If you put a comment in front of a PGC_POSTMASTER variable (and if its value differs from the default) then this should be treated as if the variable got changed and it should emmit a warning varname can only be changed on server start or similar. This warning should be kept for every other SIGHUP that gets sent just like it is done already when you change the value (but do not comment the variable). I still have the problem that the first signal I send does not trigger any message (i get the SIGHUP received, but nothing about the variable changes) but I haven't looked into it yet. Joachim ---(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 -
Thanks, You have right. It is problem with silent skip some option in
set_config_option function when PGC_SIGHUP is running context.
I fix it and I attach third version of patch.
Zdenek
Joachim Wieland wrote:
Zdenek,
On Wed, May 31, 2006 at 06:13:04PM +0200, Zdenek Kotala wrote:
Joachim, could you explain me second point? I cannot determine
described problem. By my opinion my patch does not change this behavior.
I guess what I saw was another phenomenon:
I do the following:
- vi postgresql.conf = allow_system_table_mods = true
- start postmaster
- vi postgresql.conf = # allow_system_table_mods = true (commented)
- killall -HUP postmaster
Then I get _no_ message. After another killall -HUP I do indeed get a
message. So I don't get it just for the first time which is strange, do you
see that as well?
However the message I get is that it got reset to its default value which is
wrong because its a PGC_POSTMASTER variable that can only be set at server
start (set_config_option() returns true in this case as well).
Consequently I expect to get it for every other signal I send (because the
old value is still active and differs from what is in the configuration
file).
Joachim
Index: src/backend/utils/misc/guc-file.l
===
RCS file: /projects/cvsroot/pgsql/src/backend/utils/misc/guc-file.l,v
retrieving revision 1.37
diff -c -r1.37 guc-file.l
*** src/backend/utils/misc/guc-file.l 7 Mar 2006 01:03:12 - 1.37
--- src/backend/utils/misc/guc-file.l 1 Jun 2006 14:46:56 -
***
*** 112,119
void
ProcessConfigFile(GucContext context)
{
! int elevel;
struct name_value_pair *item, *head, *tail;
Assert(context == PGC_POSTMASTER || context == PGC_SIGHUP);
--- 112,120
void
ProcessConfigFile(GucContext context)
{
! int elevel, i;
struct name_value_pair *item, *head, *tail;
+ char *env;
Assert(context == PGC_POSTMASTER || context == PGC_SIGHUP);
***
*** 150,155
--- 151,207
PGC_S_FILE, false, true);
}
+ if( context == PGC_SIGHUP)
+ {
+ /* Revert all untouched options with reset source PGC_S_FILE to
+ * default/boot value.
+ */
+ for (i = 0; i num_guc_variables; i++)
+ {
+ struct config_generic *gconf = guc_variables[i];
+ if ( gconf-context != PGC_INTERNAL gconf-context != PGC_POSTMASTER
+ !( gconf-context == PGC_BACKEND IsUnderPostmaster)
+ (gconf-reset_source == PGC_S_FILE) ( (gconf-status GUC_JUST_RELOAD) == 0) )
+ {
+ if( set_config_option(gconf-name, NULL, context,
+ PGC_S_FILE, false, true) )
+ {
+ GucStack *stack;
+ /* set correctly source */
+ gconf-reset_source = PGC_S_DEFAULT;
+ for (stack = gconf-stack; stack; stack = stack-prev)
+ {
+ if (stack-source == PGC_S_FILE)
+ {
+ stack-source = PGC_S_DEFAULT;
+ }
+ }
+
+ ereport(elevel,
+ (errcode(ERRCODE_SUCCESSFUL_COMPLETION),
+ errmsg(Configuration option %s has been revert to the boot value., gconf-name)));
+ }
+ }
+ gconf-status = ~GUC_JUST_RELOAD;
+ }
+
+ /* Revert to environment variable. PGPORT is ignored, because it cannot be
+ * set in running state.
+ */
+ env = getenv(PGDATESTYLE);
+ if (env != NULL)
+ {
+ set_config_option(datestyle, env, context,
+ PGC_S_ENV_VAR, false, true);
+ }
+
+ env = getenv(PGCLIENTENCODING);
+ if (env != NULL)
+ {
+ set_config_option(client_encoding, env, context,
+ PGC_S_ENV_VAR, false, true);
+ }
+ }
cleanup_list:
free_name_value_list(head);
}
Index: src/backend/utils/misc/guc.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/utils/misc/guc.c,v
retrieving revision 1.319
diff -c -r1.319 guc.c
*** src/backend/utils/misc/guc.c 11 May 2006 19:15:35 - 1.319
--- src/backend/utils/misc/guc.c 1 Jun 2006 14:46:56 -
***
*** 2648,2686
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;
}
case PGC_INT:
{
struct config_int *conf = (struct config_int *) gconf;
! Assert(conf-reset_val = conf-min);
! Assert(conf-reset_val = conf-max);
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, conf-reset_val);
! *conf-variable = conf-reset_val;
break;
}
case PGC_REAL:
{
struct config_real *conf = (struct config_real *) gconf;
! Assert(conf-reset_val = conf-min);
! Assert(conf-reset_val =
Re: [PATCHES] Allow commenting of variables in postgresql.conf to -
There is second version of patch. I made following changes:
- fix problem with assertion
- use boot_val instead default_val for all configuration data types
- add GUC_JUST_RELOAD status to track what is in configuration file or not
- revert only commented out variables
- add message what is revert to boot value
Joachim, could you explain me second point? I cannot determine
described problem. By my opinion my patch does not change this behavior.
Zdenek
Joachim Wieland wrote:
Zdenek,
Three points after a quick test:
- please compile with --enable-cassert, there are wrong assertions in your
code (you might just have to move some lines, there is an Assert() and an
assignment thereafter)
- changing a PGC_POSTMASTER should show a message:
= parameter \%s\ cannot be changed after server start;
configuration file change ignored
This seems to not show up anymore with your patch.
- with the same reasoning, I think it's a good idea to display a message
about which option falls back to its default value.
Joachim
Index: src/backend/utils/misc/guc-file.l
===
RCS file: /projects/cvsroot/pgsql/src/backend/utils/misc/guc-file.l,v
retrieving revision 1.37
diff -c -r1.37 guc-file.l
*** src/backend/utils/misc/guc-file.l 7 Mar 2006 01:03:12 - 1.37
--- src/backend/utils/misc/guc-file.l 31 May 2006 16:04:06 -
***
*** 112,119
void
ProcessConfigFile(GucContext context)
{
! int elevel;
struct name_value_pair *item, *head, *tail;
Assert(context == PGC_POSTMASTER || context == PGC_SIGHUP);
--- 112,120
void
ProcessConfigFile(GucContext context)
{
! int elevel, i;
struct name_value_pair *item, *head, *tail;
+ char *env;
Assert(context == PGC_POSTMASTER || context == PGC_SIGHUP);
***
*** 150,155
--- 151,205
PGC_S_FILE, false, true);
}
+ if( context == PGC_SIGHUP)
+ {
+ /* Revert all untouched options with reset source PGC_S_FILE to
+ * default/boot value.
+ */
+ for (i = 0; i num_guc_variables; i++)
+ {
+ struct config_generic *gconf = guc_variables[i];
+ if ( (gconf-reset_source == PGC_S_FILE) ( (gconf-status GUC_JUST_RELOAD) == 0) )
+ {
+ if( set_config_option(gconf-name, NULL, context,
+ PGC_S_FILE, false, true) )
+ {
+ GucStack *stack;
+ /* set correctly source */
+ gconf-reset_source = PGC_S_DEFAULT;
+ for (stack = gconf-stack; stack; stack = stack-prev)
+ {
+ if (stack-source == PGC_S_FILE)
+ {
+ stack-source = PGC_S_DEFAULT;
+ }
+ }
+
+ ereport(elevel,
+ (errcode(ERRCODE_SUCCESSFUL_COMPLETION),
+ errmsg(Configuration option %s has been revert to the boot value., gconf-name)));
+ }
+ }
+ gconf-status = ~GUC_JUST_RELOAD;
+ }
+
+ /* Revert to environment variable. PGPORT is ignored, because it cannot be
+ * set in running state.
+ */
+ env = getenv(PGDATESTYLE);
+ if (env != NULL)
+ {
+ set_config_option(datestyle, env, context,
+ PGC_S_ENV_VAR, false, true);
+ }
+
+ env = getenv(PGCLIENTENCODING);
+ if (env != NULL)
+ {
+ set_config_option(client_encoding, env, context,
+ PGC_S_ENV_VAR, false, true);
+ }
+ }
cleanup_list:
free_name_value_list(head);
}
Index: src/backend/utils/misc/guc.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/utils/misc/guc.c,v
retrieving revision 1.319
diff -c -r1.319 guc.c
*** src/backend/utils/misc/guc.c 11 May 2006 19:15:35 - 1.319
--- src/backend/utils/misc/guc.c 31 May 2006 16:04:07 -
***
*** 2648,2686
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;
}
case PGC_INT:
{
struct config_int *conf = (struct config_int *) gconf;
! Assert(conf-reset_val = conf-min);
! Assert(conf-reset_val = conf-max);
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, conf-reset_val);
! *conf-variable = conf-reset_val;
break;
}
case PGC_REAL:
{
struct config_real *conf = (struct config_real *) gconf;
! Assert(conf-reset_val = conf-min);
! Assert(conf-reset_val = conf-max);
if (conf-assign_hook)
! if (!(*conf-assign_hook) (conf-reset_val, true,
PGC_S_DEFAULT))
elog(FATAL, failed to initialize %s to %g,
! conf-gen.name, conf-reset_val);
! *conf-variable = conf-reset_val;
break;
Re: [PATCHES] Allow commenting of variables in postgresql.conf to - try2
Zdenek, On Wed, May 31, 2006 at 06:13:04PM +0200, Zdenek Kotala wrote: Joachim, could you explain me second point? I cannot determine described problem. By my opinion my patch does not change this behavior. I guess what I saw was another phenomenon: I do the following: - vi postgresql.conf = allow_system_table_mods = true - start postmaster - vi postgresql.conf = # allow_system_table_mods = true (commented) - killall -HUP postmaster Then I get _no_ message. After another killall -HUP I do indeed get a message. So I don't get it just for the first time which is strange, do you see that as well? However the message I get is that it got reset to its default value which is wrong because its a PGC_POSTMASTER variable that can only be set at server start (set_config_option() returns true in this case as well). Consequently I expect to get it for every other signal I send (because the old value is still active and differs from what is in the configuration file). Joachim ---(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
Zdenek, On Wed, May 24, 2006 at 04:27:01PM +0200, Zdenek Kotala wrote: General config structure is extend with default_val attribute to keep really default value. (There is small conflict - for string boot_val has same meaning). During reconfiguration all values which has reset source equal with PGC_S_FILE are revert back to really default values. New values from configuration files are set after this step and commented variables stay with default value. Three points after a quick test: - please compile with --enable-cassert, there are wrong assertions in your code (you might just have to move some lines, there is an Assert() and an assignment thereafter) - changing a PGC_POSTMASTER should show a message: = parameter \%s\ cannot be changed after server start; configuration file change ignored This seems to not show up anymore with your patch. - with the same reasoning, I think it's a good idea to display a message about which option falls back to its default value. Joachim ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Allow commenting of variables in postgresql.conf to
Joachim, thanks for your comments. I am working on them. Zdenek Joachim Wieland wrote: Zdenek, Three points after a quick test: - please compile with --enable-cassert, there are wrong assertions in your code (you might just have to move some lines, there is an Assert() and an assignment thereafter) - changing a PGC_POSTMASTER should show a message: = parameter \%s\ cannot be changed after server start; configuration file change ignored This seems to not show up anymore with your patch. - with the same reasoning, I think it's a good idea to display a message about which option falls back to its default value. Joachim ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[PATCHES] Allow commenting of variables in postgresql.conf to restore them to defaults
There is path implements following item from todo list: Allow
commenting of variables in postgresql.conf to restore them to defaults.
Main idea is:
General config structure is extend with default_val attribute to keep
really default value. (There is small conflict - for string boot_val has same meaning).
During reconfiguration all values which has reset source equal with
PGC_S_FILE are revert back to really default values. New values from
configuration files are set after this step and commented variables stay
with default value.
Zdenek
Index: src/backend/utils/misc/guc-file.l
===
RCS file: /projects/cvsroot/pgsql/src/backend/utils/misc/guc-file.l,v
retrieving revision 1.37
diff -r1.37 guc-file.l
115c115
intelevel;
---
intelevel, i;
116a117
char *env;
145a147,182
/* Revert all options with reset source PGC_S_FILE to default value.
* This implementation is easier then implementing some change flag and
verify
* what really was commented out.
* XXX When log_line_prefix is set in configuration file then log output
* is not correct during this phase - prefix is revert to empty value.
*/
for (i = 0; i num_guc_variables; i++)
{
struct config_generic *gconf = guc_variables[i];
if ( gconf-reset_source == PGC_S_FILE )
{
set_config_option(gconf-name, NULL, context,
PGC_S_FILE, false, true);
}
}
/* Revert to environment variable. PGPORT is ignored, because it cannot be
* set in running state. PGC_S_FILE is used instead PGC_S_ENV so as
* set_config_option can override previous defined option in config file.
* If these options are still in config file They will be overridden in
* the following step.
*/
env = getenv(PGDATESTYLE);
if (env != NULL)
{
set_config_option(datestyle, env, context,
PGC_S_FILE, false, true);
}
env = getenv(PGCLIENTENCODING);
if (env != NULL)
{
set_config_option(client_encoding, env, context,
PGC_S_FILE, false, true);
}
Index: src/backend/utils/misc/guc.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/utils/misc/guc.c,v
retrieving revision 1.319
diff -r1.319 guc.c
2651c2651
if (!(*conf-assign_hook) (conf-reset_val, true,
---
if (!(*conf-assign_hook) (conf-default_val, true,
2654,2655c2654,2655
conf-gen.name, (int) conf-reset_val);
*conf-variable = conf-reset_val;
---
conf-gen.name, (int) conf-default_val);
*conf-variable = conf-reset_val = conf-default_val;
2665c2665
if (!(*conf-assign_hook) (conf-reset_val, true,
---
if (!(*conf-assign_hook) (conf-default_val, true,
2668,2669c2668,2669
conf-gen.name, conf-reset_val);
*conf-variable = conf-reset_val;
---
conf-gen.name, conf-default_val);
*conf-variable = conf-reset_val = conf-default_val;
2679c2679
if (!(*conf-assign_hook) (conf-reset_val, true,
---
if (!(*conf-assign_hook) (conf-default_val, true,
2682,2683c2682,2683
conf-gen.name, conf-reset_val);
*conf-variable = conf-reset_val;
---
conf-gen.name, conf-default_val);
*conf-variable = conf-reset_val = conf-default_val;
3650c3650
if (changeVal !is_newvalue_equal(record, value))
---
if (changeVal value != NULL !is_newvalue_equal(record,
value))
3726c3726
makeDefault = changeVal (source = PGC_S_OVERRIDE) (value != NULL);
---
makeDefault = changeVal (source = PGC_S_OVERRIDE) (value != NULL ||
source == PGC_S_FILE);
3769,3770c3769,3781
newval = conf-reset_val;
source = conf-gen.reset_source;
---
/* Revert value to default if source is configuration file. It is used when
* configuration parameter is removed/commented out in the
config file. Else
* RESET or SET TO DEFAULT command is called and reset_val is used.
*/
if( source == PGC_S_FILE )
{
newval = conf-default_val;
}
else
{
Re: [PATCHES] Allow commenting of variables in postgresql.conf to
Zdenek Kotala wrote: There is path implements following item from todo list: Allow commenting of variables in postgresql.conf to restore them to defaults. Main idea is: General config structure is extend with default_val attribute to keep really default value. (There is small conflict - for string boot_val has same meaning). During reconfiguration all values which has reset source equal with PGC_S_FILE are revert back to really default values. New values from configuration files are set after this step and commented variables stay with default value. Please resubmit your patch as a context diff, as documented here: http://www.postgresql.org/docs/faqs.FAQ_DEV.html#item1.5 cheers andrew ---(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
Andrew Dunstan wrote:
Zdenek Kotala wrote:
There is path implements following item from todo list: Allow
commenting of variables in postgresql.conf to restore them to defaults.
Main idea is:
General config structure is extend with default_val attribute to keep
really default value. (There is small conflict - for string boot_val
has same meaning).
During reconfiguration all values which has reset source equal with
PGC_S_FILE are revert back to really default values. New values from
configuration files are set after this step and commented variables
stay with default value.
Please resubmit your patch as a context diff, as documented here:
http://www.postgresql.org/docs/faqs.FAQ_DEV.html#item1.5
cheers
andrew
I am sorry. Here it is:
Index: src/backend/utils/misc/guc-file.l
===
RCS file: /projects/cvsroot/pgsql/src/backend/utils/misc/guc-file.l,v
retrieving revision 1.37
diff -c -r1.37 guc-file.l
*** src/backend/utils/misc/guc-file.l7 Mar 2006 01:03:12 -1.37
--- src/backend/utils/misc/guc-file.l24 May 2006 14:10:12 -
***
*** 112,119
void
ProcessConfigFile(GucContext context)
{
! intelevel;
struct name_value_pair *item, *head, *tail;
Assert(context == PGC_POSTMASTER || context == PGC_SIGHUP);
--- 112,120
void
ProcessConfigFile(GucContext context)
{
! intelevel, i;
struct name_value_pair *item, *head, *tail;
+ char *env;
Assert(context == PGC_POSTMASTER || context == PGC_SIGHUP);
***
*** 143,148
--- 144,185
goto cleanup_list;
}
+ /* Revert all options with reset source PGC_S_FILE to default value.
+ * This implementation is easier then iplementing some change flag
and verify
+ * what realy was commented out.
+ * XXX When log_line_prefix is set in configuration file then log
output
+ * is not correct during this phase - prefix is revert to empty value.
+ */
+ for (i = 0; i num_guc_variables; i++)
+ {
+ struct config_generic *gconf = guc_variables[i];
+ if ( gconf-reset_source == PGC_S_FILE )
+ {
+ set_config_option(gconf-name, NULL, context,
+ PGC_S_FILE, false, true);
+ }
+ }
+
+ /* Revert to environment variable. PGPORT is ignored, because it
cannot be
+ * set in running state. PGC_S_FILE is used instead PGC_S_ENV so as
+ * set_config_option can override previous defined option in
config file.
+ * If these options are still in config file They will be
overriden in
+ * the following step.
+ */
+ env = getenv(PGDATESTYLE);
+ if (env != NULL)
+ {
+ set_config_option(datestyle, env, context,
+ PGC_S_FILE, false, true);
+ }
+
+ env = getenv(PGCLIENTENCODING);
+ if (env != NULL)
+ {
+ set_config_option(client_encoding, env, context,
+ PGC_S_FILE, false, true);
+ }
+
/* If we got here all the options checked out okay, so apply them. */
for (item = head; item; item = item-next)
{
Index: src/backend/utils/misc/guc.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/utils/misc/guc.c,v
retrieving revision 1.319
diff -c -r1.319 guc.c
*** src/backend/utils/misc/guc.c11 May 2006 19:15:35 -1.319
--- src/backend/utils/misc/guc.c24 May 2006 14:10:12 -
***
*** 2648,2658
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;
}
case PGC_INT:
--- 2648,2658
struct config_bool *conf = (struct config_bool *)
gconf;
if (conf-assign_hook)
! if (!(*conf-assign_hook) (conf-default_val,
true,
PGC_S_DEFAULT))
elog(FATAL, failed to initialize %s to %d,
! conf-gen.name, (int) conf-default_val);
! *conf-variable = conf-reset_val = conf-default_val;
break;
}
case PGC_INT:
***
*** 2662,2672
Assert(conf-reset_val = conf-min);
Assert(conf-reset_val = conf-max);
if (conf-assign_hook)
! if (!(*conf-assign_hook) (conf-reset_val, true,
Re: [PATCHES] Allow commenting of variables in postgresql.conf to
Zdenek Kotala wrote: Andrew Dunstan wrote: Zdenek Kotala wrote: There is path implements following item from todo list: Allow commenting of variables in postgresql.conf to restore them to defaults. Main idea is: General config structure is extend with default_val attribute to keep really default value. (There is small conflict - for string boot_val has same meaning). During reconfiguration all values which has reset source equal with PGC_S_FILE are revert back to really default values. New values from configuration files are set after this step and commented variables stay with default value. Please resubmit your patch as a context diff, as documented here: http://www.postgresql.org/docs/faqs.FAQ_DEV.html#item1.5 I am sorry. Here it is: Please resubmit as an attachment, or disallow your mail client from munging whitespace ... I see wrapped words here, and apparently tab expansion as well. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] Allow commenting of variables in postgresql.conf to
Alvaro Herrera wrote:
Zdenek Kotala wrote:
Zdenek Kotala wrote:
There is path implements following item from todo list: Allow
commenting of variables in postgresql.conf to restore them to defaults.
Main idea is:
General config structure is extend with default_val attribute to keep
really default value. (There is small conflict - for string boot_val
has same meaning).
During reconfiguration all values which has reset source equal with
PGC_S_FILE are revert back to really default values. New values from
configuration files are set after this step and commented variables
stay with default value.
Please resubmit as an attachment, or disallow your mail client from
munging whitespace ... I see wrapped words here, and apparently tab
expansion as well.
OK. Here is patch like attachment.
Zdenek
Index: src/backend/utils/misc/guc-file.l
===
RCS file: /projects/cvsroot/pgsql/src/backend/utils/misc/guc-file.l,v
retrieving revision 1.37
diff -c -r1.37 guc-file.l
*** src/backend/utils/misc/guc-file.l 7 Mar 2006 01:03:12 - 1.37
--- src/backend/utils/misc/guc-file.l 24 May 2006 14:10:12 -
***
*** 112,119
void
ProcessConfigFile(GucContext context)
{
! int elevel;
struct name_value_pair *item, *head, *tail;
Assert(context == PGC_POSTMASTER || context == PGC_SIGHUP);
--- 112,120
void
ProcessConfigFile(GucContext context)
{
! int elevel, i;
struct name_value_pair *item, *head, *tail;
+ char *env;
Assert(context == PGC_POSTMASTER || context == PGC_SIGHUP);
***
*** 143,148
--- 144,185
goto cleanup_list;
}
+ /* Revert all options with reset source PGC_S_FILE to default value.
+ * This implementation is easier then iplementing some change flag and verify
+ * what realy was commented out.
+ * XXX When log_line_prefix is set in configuration file then log output
+ * is not correct during this phase - prefix is revert to empty value.
+ */
+ for (i = 0; i num_guc_variables; i++)
+ {
+ struct config_generic *gconf = guc_variables[i];
+ if ( gconf-reset_source == PGC_S_FILE )
+ {
+ set_config_option(gconf-name, NULL, context,
+ PGC_S_FILE, false, true);
+ }
+ }
+
+ /* Revert to environment variable. PGPORT is ignored, because it cannot be
+ * set in running state. PGC_S_FILE is used instead PGC_S_ENV so as
+ * set_config_option can override previous defined option in config file.
+ * If these options are still in config file They will be overriden in
+ * the following step.
+ */
+ env = getenv(PGDATESTYLE);
+ if (env != NULL)
+ {
+ set_config_option(datestyle, env, context,
+ PGC_S_FILE, false, true);
+ }
+
+ env = getenv(PGCLIENTENCODING);
+ if (env != NULL)
+ {
+ set_config_option(client_encoding, env, context,
+ PGC_S_FILE, false, true);
+ }
+
/* If we got here all the options checked out okay, so apply them. */
for (item = head; item; item = item-next)
{
Index: src/backend/utils/misc/guc.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/utils/misc/guc.c,v
retrieving revision 1.319
diff -c -r1.319 guc.c
*** src/backend/utils/misc/guc.c 11 May 2006 19:15:35 - 1.319
--- src/backend/utils/misc/guc.c 24 May 2006 14:10:12 -
***
*** 2648,2658
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;
}
case PGC_INT:
--- 2648,2658
struct config_bool *conf = (struct config_bool *) gconf;
if (conf-assign_hook)
! if (!(*conf-assign_hook) (conf-default_val, true,
PGC_S_DEFAULT))
elog(FATAL, failed to initialize %s to %d,
! conf-gen.name, (int) conf-default_val);
! *conf-variable = conf-reset_val = conf-default_val;
break;
}
case PGC_INT:
***
*** 2662,2672
Assert(conf-reset_val = conf-min);
Assert(conf-reset_val = conf-max);
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, conf-reset_val);
! *conf-variable = conf-reset_val;
break;
}
case PGC_REAL:
--- 2662,2672
Assert(conf-reset_val = conf-min);
Assert(conf-reset_val = conf-max);
if (conf-assign_hook)
! if (!(*conf-assign_hook) (conf-default_val, true,
PGC_S_DEFAULT))
elog(FATAL, failed to initialize %s to %d,
! conf-gen.name, conf-default_val);
!
