Allow the postmaster to accept changes in PGC_BACKEND GUC variables

from the config file, so that these changes will propagate to backends
started later.  Already-started backends continue to ignore changes
in these variables.

doc/src/sgml/runtime.sgml

 <!--
-$Header: /cvsroot/pgsql/doc/src/sgml/runtime.sgml,v 1.86 2001/09/30 18:57:45 tgl Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/runtime.sgml,v 1.87 2001/09/30 20:16:21 tgl Exp $
 -->
 
 <Chapter Id="runtime">
@@ -845,10 +845,11 @@ env PGOPTIONS='-c geqo=off' psql
       <term><varname>LOG_CONNECTIONS</varname> (<type>boolean</type>)</term>
       <listitem>
        <para>
-        Prints a line informing about each successful connection to
+        Prints a line informing about each successful connection in
         the server log. This is off by default, although it is
         probably very useful. This option can only be set at server
-        start.
+        start or in the <filename>postgresql.conf</filename>
+        configuration file.
        </para>
       </listitem>
      </varlistentry>
@@ -1223,7 +1224,7 @@ dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir'
       <listitem>
        <para>
         Sets the maximum number of simultaneously open files in each server
-	process.  The default is 1000.  The limit actually used by the code
+	subprocess.  The default is 1000.  The limit actually used by the code
 	is the smaller of this setting and the result of
 	<literal>sysconf(_SC_OPEN_MAX)</literal>.
 	Therefore, on systems where sysconf returns a reasonable limit,
@@ -1233,7 +1234,10 @@ dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir'
 	processes all try to open that many files.  If you find yourself
 	seeing <quote>Too many open files</> failures, try reducing this
 	setting.
-        This option can only be set at server start.
+        This option can only be set at server start or in the
+	<filename>postgresql.conf</filename> configuration file;
+	if changed in the configuration file, it only affects
+	subsequently-started server subprocesses.
        </para>
       </listitem>
      </varlistentry>

src/backend/utils/misc/guc.c

@@ -4,7 +4,7 @@
  * Support for grand unified configuration scheme, including SET
  * command, configuration file, and command line options.
  *
- * $Header: /cvsroot/pgsql/src/backend/utils/misc/guc.c,v 1.54 2001/09/30 18:57:45 tgl Exp $
+ * $Header: /cvsroot/pgsql/src/backend/utils/misc/guc.c,v 1.55 2001/09/30 20:16:21 tgl Exp $
  *
  * Copyright 2000 by PostgreSQL Global Development Group
  * Written by Peter Eisentraut <peter_e@gmx.net>.
@@ -704,37 +704,49 @@ set_config_option(const char *name, const char *value,
 	 * precise rules. Note that we don't want to throw errors if we're in
 	 * the SIGHUP context. In that case we just ignore the attempt.
 	 */
-	if (record->context == PGC_POSTMASTER && context != PGC_POSTMASTER)
+	switch (record->context)
 	{
-		if (context != PGC_SIGHUP)
-			elog(ERROR, "'%s' cannot be changed after server start", name);
-		else
+		case PGC_POSTMASTER:
+			if (context == PGC_SIGHUP)
 				return true;
-	}
-	else if (record->context == PGC_SIGHUP && context != PGC_SIGHUP &&
-			 context != PGC_POSTMASTER)
-	{
+			if (context != PGC_POSTMASTER)
+				elog(ERROR, "'%s' cannot be changed after server start", name);
+			break;
+		case PGC_SIGHUP:
+			if (context != PGC_SIGHUP && context != PGC_POSTMASTER)
 				elog(ERROR, "'%s' cannot be changed now", name);
-
 			/*
 			 * Hmm, the idea of the SIGHUP context is "ought to be global, but
 			 * can be changed after postmaster start". But there's nothing
 			 * that prevents a crafty administrator from sending SIGHUP
 			 * signals to individual backends only.
 			 */
-	}
-	else if (record->context == PGC_BACKEND && context != PGC_BACKEND
-			 && context != PGC_POSTMASTER)
+			break;
+		case PGC_BACKEND:
+			if (context == PGC_SIGHUP)
 			{
-		if (context != PGC_SIGHUP)
-			elog(ERROR, "'%s' cannot be set after connection start", name);
-		else
+				/*
+				 * If a PGC_BACKEND parameter is changed in the config file,
+				 * we want to accept the new value in the postmaster (whence
+				 * it will propagate to subsequently-started backends), but
+				 * ignore it in existing backends.  This is a tad klugy, but
+				 * necessary because we don't re-read the config file during
+				 * backend start.
+				 */
+				if (IsUnderPostmaster)
 					return true;
 			}
-	else if (record->context == PGC_SUSET &&
-			 (context == PGC_USERSET || context == PGC_BACKEND))
+			else if (context != PGC_BACKEND && context != PGC_POSTMASTER)
+				elog(ERROR, "'%s' cannot be set after connection start", name);
+			break;
+		case PGC_SUSET:
+			if (context == PGC_USERSET || context == PGC_BACKEND)
 				elog(ERROR, "permission denied");
-
+			break;
+		case PGC_USERSET:
+			/* always okay */
+			break;
+	}
 
 	/*
 	 * Evaluate value and set variable

src/include/utils/guc.h

@@ -4,7 +4,7 @@
  * External declarations pertaining to backend/utils/misc/guc.c and
  * backend/utils/misc/guc-file.l
  *
- * $Id: guc.h,v 1.9 2001/06/18 16:14:43 momjian Exp $
+ * $Id: guc.h,v 1.10 2001/09/30 20:16:21 tgl Exp $
  */
 #ifndef GUC_H
 #define GUC_H
@@ -23,11 +23,12 @@
  * certain point in their main loop. It's safer to wait than to read a
  * file asynchronously.)
  *
- * BACKEND options can only be set at postmaster startup or with the
- * PGOPTIONS variable from the client when the connection is
- * initiated. Note that you cannot change this kind of option using
- * the SIGHUP mechanism, that would defeat the purpose of this being
- * fixed for a given backend once started.
+ * BACKEND options can only be set at postmaster startup, from the
+ * configuration file, or with the PGOPTIONS variable from the client
+ * when the connection is initiated.  Furthermore, an already-started
+ * backend will ignore changes to such an option in the configuration
+ * file.  The idea is that these options are fixed for a given backend
+ * once it's started, but they can vary across backends.
  *
  * SUSET options can be set at postmaster startup, with the SIGHUP
  * mechanism, or from SQL if you're a superuser. These options cannot