Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id BF08F1337C2E for ; Tue, 15 Mar 2011 12:32:28 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.29]) (amavisd-maia, port 10024) with ESMTP id 15562-06 for ; Tue, 15 Mar 2011 15:32:18 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from momjian.us (momjian.us [70.90.9.53]) by mail.postgresql.org (Postfix) with ESMTP id 1066C1337BE4 for ; Tue, 15 Mar 2011 12:32:13 -0300 (ADT) Received: (from bruce@localhost) by momjian.us (8.11.6/8.11.6) id p2FFWBS24630; Tue, 15 Mar 2011 11:32:11 -0400 (EDT) From: Bruce Momjian Message-Id: <201103151532.p2FFWBS24630@momjian.us> Subject: Re: explaining "context" column of pg_settings In-Reply-To: To: Robert Haas Date: Tue, 15 Mar 2011 11:32:11 -0400 (EDT) CC: Tom Lane , Josh Kupershmidt , pgsql-docs X-Mailer: ELM [version 2.4ME+ PL124 (25)] MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="ELM1300203131-19857-0_" Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.91 tagged_above=-5 required=5 tests=BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: X-Archive-Number: 201103/97 X-Sequence-Number: 6530 --ELM1300203131-19857-0_ Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Robert Haas wrote: > On Fri, Mar 11, 2011 at 12:37 PM, Tom Lane wrote: > > Bruce Momjian writes: > >> Robert Haas wrote: > >>> Please propose a specific patch so we can complain about it. ?:-) > > > >> I am proposing Tom's: > >> ? ? ? http://archives.postgresql.org/pgsql-docs/2010-12/msg00003.php > > That's actually a link to Josh's message, not the one from Tom; I > assume you mean the patch in Tom's reply. > > > It still seems like that material doesn't belong there. ?However, it's > > largely a restatement of what's said in section 18.1 in a form that > > matches up with the presentation used in the pg_settings view. ?Maybe > > it's okay to apply it as-is and just check to make sure that 18.1 is not > > missing any facts given here. > > AFAICS 18.1 doesn't really contain a clear enumeration of all the > different settings types. We ought to have that somewhere. I took Tom's patch, applied it, and added appropriate text and links to address the issues raised in this thread. Patch attached. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + --ELM1300203131-19857-0_ Content-Transfer-Encoding: 7bit Content-Type: text/x-diff Content-Disposition: inline; filename="/pgpatches/guc" diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml new file mode 100644 index 64d1cda..d0a8dc7 *** a/doc/src/sgml/catalogs.sgml --- b/doc/src/sgml/catalogs.sgml *************** *** 7628,7634 **** context text ! Context required to set the parameter's value vartype --- 7628,7634 ---- context text ! Context required to set the parameter's value (see below) vartype *************** *** 7693,7698 **** --- 7693,7790 ---- + There are several possible values of context. + In order of decreasing difficulty of changing the setting, they are: + + + + + internal + + + These settings cannot be changed directly; they reflect internally + determined values. Some of them may be adjustable by rebuilding the + server with different configuration options, or by changing options + supplied to initdb. + + + + + postmaster + + + These settings can only be applied when the server starts, so any change + requires restarting the server. Values for these settings are typically + stored in the postgresql.conf file, or passed on + the command line when starting the server. Of course, settings with any + of the lower context types can also be + set at server start time. + + + + + sighup + + + Changes to these settings can be made in + postgresql.conf without restarting the server. + Send a SIGHUP signal to the postmaster to + cause it to re-read postgresql.conf and apply + the changes. The postmaster will also forward the + SIGHUP signal to its child processes so that + they all pick up the new value. + + + + + backend + + + Changes to these settings can be made in + postgresql.conf without restarting the server; + they can also be set for a particular session in the connection request + packet (for example, via libpq's PGOPTIONS + environment variable). However, these settings never change in a + session after it is started. If you change them in + postgresql.conf, send a + SIGHUP signal to the postmaster to cause it to + re-read postgresql.conf. The new values will only + affect subsequently-launched sessions. + + + + + superuser + + + These settings can be set from postgresql.conf, + or within a session via the SET command; but only superusers + can change them via SET. Changes in + postgresql.conf will affect existing sessions + only if no session-local value has been established with SET. + + + + + user + + + These settings can be set from postgresql.conf, + or within a session via the SET command. Any user is + allowed to change his session-local value. Changes in + postgresql.conf will affect existing sessions + only if no session-local value has been established with SET. + + + + + + + See for more information about the various + ways to change these parameters. + + + The pg_settings view cannot be inserted into or deleted from, but it can be updated. An UPDATE applied to a row of pg_settings is equivalent to executing diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml new file mode 100644 index a4c1e84..a55a800 *** a/doc/src/sgml/config.sgml --- b/doc/src/sgml/config.sgml *************** SET ENABLE_SEQSCAN TO OFF; *** 166,175 **** ! The virtual table pg_settings ! (described in ) also allows ! displaying and updating session run-time parameters. It is equivalent ! to SHOW and SET, but can be more convenient to use because it can be joined with other tables, or selected from using any desired selection condition. It also contains more information about what values are allowed for the parameters. --- 166,177 ---- ! The virtual table pg_settings also allows ! displaying and updating session run-time parameters; see for details and a description of the ! different variable types and when they can be changed. ! pg_settings is equivalent to SHOW ! and SET, but can be more convenient to use because it can be joined with other tables, or selected from using any desired selection condition. It also contains more information about what values are allowed for the parameters. --ELM1300203131-19857-0_--