View Issue Details

IDProjectCategoryView StatusLast Update
0000114Pgpool-IIBugpublic2014-10-22 22:01
ReportermarkhAssigned Tonagata 
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
PlatformX86-64OSCentOSOS Version6
Product Version 
Target VersionFixed in Version 
Summary0000114: Can't disable debug logging after enabling it with a config reload
DescriptionIt is possible to turn on debug logging by changing the debug_level setting in the config file to 1 and then reloading the config.

However, it is not possible to reverse this by setting debug_level back to 0 and reloading again. After this, debug logging is still enabled.

It is sometimes useful to temporarily enable debug logging in a running system. In production systems, it is not desirable to have to stop and restart pgpool to turn off debug logging again.
Steps To ReproduceStart pgpool.
In pgpool.conf, set debug_level=1.
Run "pgpool reload".
Observe that debug logging is now enabled.

In pgpool.conf, set debug_level=0.
Run "pgpool reload".
Observe that debug logging is still happening - it has not been disabled.
Additional InformationIn pool_config.c, function pool_get_config, the code responsible for this behaviour is at line 4271:

/* Consider -d option value stored in pool_config already */
pool_config->debug_level |= v;

This will only ever allow debug_level to be set to 1, never back to 0, by a config reload. I gather this is deliberate, to prevent the config setting from cancelling out a command line -d option (or to allow the command line option to override the config), but the inability to turn off debug logging without restarting is an unfortunate side effect.

Perhaps what is needed here is to save the command line options and re-apply them before reloading the config.
TagsNo tags attached.

Activities

nagata

2014-09-17 21:12

developer   ~0000473

You are right. This intended to prevent the config setting (debug_level = 0)
from overwriting -d option. Otherwise, some debug messages during reading
config setting could never be output. However, I had overlooked what happens
if config setting is reloaded when pool_config->debug_level == 1.

I fixed to use debug_level directive value at reload context.
The patch is attached.

nagata

2014-09-17 21:12

developer  

pool_config.patch (597 bytes)
diff --git a/pool_config.l b/pool_config.l
index dcf3e7c..ce4c351 100644
--- a/pool_config.l
+++ b/pool_config.l
@@ -2543,7 +2543,10 @@ int pool_get_config(char *confpath, POOL_CONFIG_CONTEXT context)
 				return(-1);
 			}
 			/* Consider -d option value stored in pool_config already */
-			pool_config->debug_level |= v;
+			if (CHECK_CONTEXT(INIT_CONFIG, context))
+				pool_config->debug_level |= v;
+			else if (CHECK_CONTEXT(RELOAD_CONFIG, context))
+				pool_config->debug_level = v;
 		}
 
 		else if (!strcmp(key, "relcache_expire") && CHECK_CONTEXT(INIT_CONFIG|RELOAD_CONFIG, context))
pool_config.patch (597 bytes)

nagata

2014-10-22 21:56

developer   ~0000475

commited

Issue History

Date Modified Username Field Change
2014-09-15 22:45 markh New Issue
2014-09-16 23:32 t-ishii Assigned To => nagata
2014-09-16 23:32 t-ishii Status new => assigned
2014-09-17 21:12 nagata Note Added: 0000473
2014-09-17 21:12 nagata File Added: pool_config.patch
2014-09-17 21:12 nagata Status assigned => resolved
2014-09-17 21:12 nagata Resolution open => fixed
2014-09-17 21:14 administrator Status resolved => feedback
2014-09-17 21:14 administrator Resolution fixed => reopened
2014-10-22 21:56 nagata Note Added: 0000475
2014-10-22 21:56 nagata Status feedback => closed
2014-10-22 21:56 nagata Resolution reopened => fixed
2014-10-22 22:01 nagata Changeset attached => pgpool2 V3_1_STABLE 27cf0a25
2014-10-22 22:01 nagata Changeset attached => pgpool2 V3_0_STABLE c9e66e2b