Thread: Proposal to Re-Order Postgresql.Conf, part II
Folks, Last we talked (before the mail server went down) Tom had agreed in principle to a re-ordering of postgresql.conf.sample and the "Run-Time Configuration" docs page based on the attached ordering file. I would like to make this happen before feature-freeze on June 15. To do that, I need more info: 1) Are any additional changes expected for GUC.c before feature-freeze? 2) Are all of the new GUC.c variables for 7.4 already documented in the CVS docs? If not, can the responsible parties send me descriptions so that I can doc it? 3) Do people want me to take a stab at re-ordering GUC.c as well (that is, Tom's idea of having the GUC.c ordering alphabetical within each variable type), considering that I am not a C programmer? 4) Does anyone else have any comments on the proposed re-ordering? -- Josh Berkus Aglio Database Solutions San Francisco
Josh Berkus <josh@agliodbs.com> writes:
> 1) Are any additional changes expected for GUC.c before feature-freeze?
I'm still thinking of adding an am_superuser variable so that psql can
rely on the new ParameterStatus mechanism instead of explicit queries to
find out if you're superuser. But this would be a read-only variable
and so should not appear in postgresql.conf. Offhand I'm not aware of
any other proposed additions ... but something might turn up.
> 2) Are all of the new GUC.c variables for 7.4 already documented in the CVS
> docs?
They should be.
regards, tom lane
On Thu, 2003-06-05 at 11:23, Josh Berkus wrote:
>
> 4) Does anyone else have any comments on the proposed re-ordering?
>
I think this was touched on before, but was there a final determination
of the ordering of the "show all" command? I'm hoping that will return
in the new order of the postgresql.conf
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
> 4) Does anyone else have any comments on the proposed re-ordering? Since we're painting a shed, does it make sense to put the items in alphabetical order for each section? -- Rod Taylor <rbt@rbt.ca> PGP Key: http://www.rbt.ca/rbtpub.asc
On Thu, 2003-06-05 at 14:16, Josh Berkus wrote: > Rod, > > > > 4) Does anyone else have any comments on the proposed re-ordering? > > > > Since we're painting a shed, does it make sense to put the items in > > alphabetical order for each section? > > I thought about that, yes. However, I find that most items have a logical > order that is not alphabetical. Take the WAL section for example: Excellent point. > BTW, everyone: I do not seem to be receiving any Postgresql.org mail since > the server crash & restoration. So please cc: any comments directly to me! You re-subscribed I assume... -- Rod Taylor <rbt@rbt.ca> PGP Key: http://www.rbt.ca/rbtpub.asc
Rod, > > 4) Does anyone else have any comments on the proposed re-ordering? > > Since we're painting a shed, does it make sense to put the items in > alphabetical order for each section? I thought about that, yes. However, I find that most items have a logical order that is not alphabetical. Take the WAL section for example: "fsync" needs to go first, because if it is set to "false" the rest of the WAL settings don't matter. "wal_sync_method" and "wal_buffers" are the "most important" (or, at least, most likely to be tinkered with) settings so they sould go immdiately after. "checkpoint_segments, checkpoint_timeout, commit_delay, commit_siblings" are all directly related and should to appear in that order (which, oddly enough, happens to be alphabetical). "wal_debug" is seldom used outside of Postgresql source development or unusual system failures, and should therefore go last. I have tried to order other parameters by applying the same logic, which essentially amounts to: order by most important/most likely to be changed, grouping settings that need to be manipulated together. I'd be happy to hear your comments on my application of that logic. BTW, everyone: I do not seem to be receiving any Postgresql.org mail since the server crash & restoration. So please cc: any comments directly to me! -- -Josh BerkusAglio Database SolutionsSan Francisco
I kind of prefer the way things were grouped together in 7.2 vs. 7.3. If I
needed to check out connection information or look at query tuning flags,
they were all right next to each other and I didn't have to scroll back and
forth through the list. Luckily most of the topical variables share somewhat
common names (max_fsm_relations and max_fsm_pages) or else it would really be
easy to overlook some settings.
Robert Treat
On Saturday 07 June 2003 12:33 pm, Bruce Momjian wrote:
> I think people thought if you were doing SHOW ALL, you were looking for
> a specific variable, so alphabetical was best.
>
> ---------------------------------------------------------------------------
>
> Robert Treat wrote:
> > On Thu, 2003-06-05 at 11:23, Josh Berkus wrote:
> > > 4) Does anyone else have any comments on the proposed re-ordering?
> >
> > I think this was touched on before, but was there a final determination
> > of the ordering of the "show all" command? I'm hoping that will return
> > in the new order of the postgresql.conf
> >
> > Robert Treat
> > --
> > Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
> >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 6: Have you searched our list archives?
> >
> > http://archives.postgresql.org
Josh Berkus <josh@agliodbs.com> writes:
> "wal_debug" is seldom used outside of Postgresql source development or unusual
> system failures, and should therefore go last.
BTW, it occurs to me that wal_debug is one of the hacker-only variables
that probably ought not be documented at all. I cannot imagine any use
for it for the average DBA.
regards, tom lane
I think people thought if you were doing SHOW ALL, you were looking for
a specific variable, so alphabetical was best.
---------------------------------------------------------------------------
Robert Treat wrote:
> On Thu, 2003-06-05 at 11:23, Josh Berkus wrote:
> >
> > 4) Does anyone else have any comments on the proposed re-ordering?
> >
>
> I think this was touched on before, but was there a final determination
> of the ordering of the "show all" command? I'm hoping that will return
> in the new order of the postgresql.conf
>
> Robert Treat
> --
> Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073
Robert Treat <xzilla@users.sourceforge.net> writes:
> I think this was touched on before, but was there a final determination
> of the ordering of the "show all" command?
SHOW ALL will remain alphabetical.
regards, tom lane
Josh Berkus <josh@agliodbs.com> writes:
> Hey, I'm looking at the postgresql.conf.sample in CVS, and can't find the
> option that's supposed to let you turn off "Inserting missing FROM clause for
> table ..."
Bruce hasn't applied that patch yet. I believe he's starting to catch
up the patch backlog today, though.
BTW there is also a pending patch that will add a GUC variable to
control "rendezvous" on Darwin. I had forgotten what-all was in the
patch queue until I looked this morning.
regards, tom lane
Tom, > Bruce hasn't applied that patch yet. I believe he's starting to catch > up the patch backlog today, though. > > BTW there is also a pending patch that will add a GUC variable to > control "rendezvous" on Darwin. I had forgotten what-all was in the > patch queue until I looked this morning. Well, all I need right now is names for those options. Can you give me that? Thanks! -- -Josh BerkusAglio Database SolutionsSan Francisco
Tom, Justin, > Um, not documenting it is probably not a good move for us, however putting > it at the end in a section marked "Developer Focused" or something similar > would probably have the right mix of messages. i.e. "hands off" + "not a > performance tweak", etc. So, proposal: 1) wal_debug and the various trace_locks options will not be included in postgresql.conf.sample 2) they will, however, be included in the "Run Time Configuration" page, under a secion entitled "Source Develoment Options" Work for everybody? -- Josh Berkus Aglio Database Solutions San Francisco
Tom, Hey, I'm looking at the postgresql.conf.sample in CVS, and can't find the option that's supposed to let you turn off "Inserting missing FROM clause for table ..." I thought that patch was accepted 3 weeks ago? Is this just missing from postgresql.conf.sample? -- -Josh BerkusAglio Database SolutionsSan Francisco
Tom Lane wrote: > Josh Berkus <josh@agliodbs.com> writes: > >>"wal_debug" is seldom used outside of Postgresql source development or unusual >>system failures, and should therefore go last. > > BTW, it occurs to me that wal_debug is one of the hacker-only variables > that probably ought not be documented at all. I cannot imagine any use > for it for the average DBA. Um, not documenting it is probably not a good move for us, however putting it at the end in a section marked "Developer Focused"or something similar would probably have the right mix of messages. i.e. "hands off" + "not a performance tweak", etc. :-) Regards and best wishes, Justin Clift > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
Folks, Attached is another order outline for the Postgresql.conf parameters, updated for 7.4. Please examine it, and then give your opinions on the following: 1) Should "enable_implicit_from" go in the "Version/Platform Compatibility" section where I have it now, or in "CLIENT CONNECTIONS-Statement Behavior", or somewhere else? 2) Where should "preload_libraries" go? I'm very reluctant to start a "Misc." section. 3) I have re-ordered each subsection somewhat. The fixed ordering is based on:a) My guess at the frequency with which that option will be changed, with more common options toward the top of the subsection;b) Grouping for tightly related options and for options that cascade;c)where (a) and (b) are unclear, alpha order. Does this order make sense looking at the file? 3) Should we use indenting in PostgreSQL.conf.sample? I tend to think it would make the file easier to read, but I'm not sure what effect it would have, if any, on parsing the file and whether other people would find it easy to read. -- -Josh BerkusAglio Database SolutionsSan Francisco
Josh Berkus wrote: > Tom, Justin, > > > Um, not documenting it is probably not a good move for us, however putting > > it at the end in a section marked "Developer Focused" or something similar > > would probably have the right mix of messages. i.e. "hands off" + "not a > > performance tweak", etc. > > So, proposal: > > 1) wal_debug and the various trace_locks options will not be included in > postgresql.conf.sample Attached is the patch I will apply. > 2) they will, however, be included in the "Run Time Configuration" page, under > a secion entitled "Source Develoment Options" Makes sense, I guess. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 Index: src/backend/utils/misc/guc.c =================================================================== RCS file: /cvsroot/pgsql-server/src/backend/utils/misc/guc.c,v retrieving revision 1.127 diff -c -c -r1.127 guc.c *** src/backend/utils/misc/guc.c 28 May 2003 18:19:09 -0000 1.127 --- src/backend/utils/misc/guc.c 2 Jun 2003 16:03:20 -0000 *************** *** 689,694 **** --- 689,695 ---- 60, 1, 600, NULL, NULL }, + /* Not for general use */ { {"pre_auth_delay", PGC_SIGHUP}, &PreAuthDelay, 0, 0, 60, NULL, NULL *************** *** 871,876 **** --- 872,878 ---- "$user,public", assign_search_path, NULL }, + /* Can't be set in postgresql.conf */ { {"server_encoding", PGC_INTERNAL, GUC_REPORT}, &server_encoding_string, *************** *** 888,893 **** --- 890,896 ---- "notice", assign_log_min_messages, NULL }, + /* Not for general use --- used by SET SESSION AUTHORIZATION */ { {"session_authorization", PGC_USERSET, GUC_NO_SHOW_ALL | GUC_NO_RESET_ALL}, &session_authorization_string, Index: src/backend/utils/misc/postgresql.conf.sample =================================================================== RCS file: /cvsroot/pgsql-server/src/backend/utils/misc/postgresql.conf.sample,v retrieving revision 1.78 diff -c -c -r1.78 postgresql.conf.sample *** src/backend/utils/misc/postgresql.conf.sample 14 May 2003 03:26:02 -0000 1.78 --- src/backend/utils/misc/postgresql.conf.sample 2 Jun 2003 16:03:20 -0000 *************** *** 182,201 **** # - # Lock Tracing - # - #trace_notify = false - - # requires LOCK_DEBUG - #trace_locks = false - #trace_userlocks = false - #trace_lwlocks = false - #debug_deadlocks = false - #trace_lock_oidmin = 16384 - #trace_lock_table = 0 - - - # # Misc # #dynamic_library_path = '$libdir' --- 182,187 ----
Josh Berkus wrote: > Tom, > > Hey, I'm looking at the postgresql.conf.sample in CVS, and can't find the > option that's supposed to let you turn off "Inserting missing FROM clause for > table ..." > > I thought that patch was accepted 3 weeks ago? Is this just missing from > postgresql.conf.sample? It is in the patch queue --- I am applying tomorrow. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
On Mon, 9 Jun 2003, Tom Lane wrote: > Josh Berkus <josh@agliodbs.com> writes: > > Hey, I'm looking at the postgresql.conf.sample in CVS, and can't find the > > option that's supposed to let you turn off "Inserting missing FROM clause for > > table ..." > > Bruce hasn't applied that patch yet. I believe he's starting to catch > up the patch backlog today, though. > Are you sure about that? I seem to remember seeing the "will be applied within 24 hours" message a couple of weeks or so ago now. Is this a feature of the recent system problems and lost patches are having to be reapplied? As for it's name Josh, sorry, I don't have a record of my patch and the name used in the patch differs to that which I have in my source tree. -- Nigel Andrews
Nigel J. Andrews wrote: > On Mon, 9 Jun 2003, Tom Lane wrote: > > > Josh Berkus <josh@agliodbs.com> writes: > > > Hey, I'm looking at the postgresql.conf.sample in CVS, and can't find the > > > option that's supposed to let you turn off "Inserting missing FROM clause for > > > table ..." > > > > Bruce hasn't applied that patch yet. I believe he's starting to catch > > up the patch backlog today, though. > > > > Are you sure about that? I seem to remember seeing the "will be applied within > 24 hours" message a couple of weeks or so ago now. Is this a feature of the > recent system problems and lost patches are having to be reapplied? > > As for it's name Josh, sorry, I don't have a record of my patch and the name > used in the patch differs to that which I have in my source tree. Yes, it is in the queue: http://momjian.postgresql.org/cgi-bin/pgpatches Because of my Win32 work, I couldn't follow the 24/48 hours limit. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Justin Clift wrote: > Tom Lane wrote: >> Josh Berkus <josh@agliodbs.com> writes: >> >>>"wal_debug" is seldom used outside of Postgresql source development or unusual >>>system failures, and should therefore go last. >> >> BTW, it occurs to me that wal_debug is one of the hacker-only variables >> that probably ought not be documented at all. I cannot imagine any use >> for it for the average DBA. > > Um, not documenting it is probably not a good move for us, however putting it at the end in a section marked "DeveloperFocused" or something similar would > probably have the right mix of messages. i.e. "hands off" + "not a performance tweak", etc. No, not documenting it IS a good move. If there's a button people will press it, if there's a switch people will turn it on and if there's a slot people will stick in whatever they have ... believe it or not, I have found a Xmas cookie in the floppy drive of a consultant's notebook and a secretary once managed to get a 5.25'' floppy "into" an IBM PS/2 ... er ... yes, there was some kind of venting slot somewhere ... I did not try to explain the difference between a floppy drive and a venting slot to her, I converted it to the "right" format and the next time she came with a 5.25'' floppy directly to me :-) Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
Jan, > No, not documenting it IS a good move. I couldn't disagree more. Undocumented options? Who are we, Microsoft? > If there's a button people will > press it, if there's a switch people will turn it on and if there's a > slot people will stick in whatever they have ... believe it or not, I > have found a Xmas cookie in the floppy drive of a consultant's notebook <snip> These kinds of people don't read the documentation in the first place, so we're in no danger from them. I can definitely see an argument that the "developer" switches should be documented on a different page of the docs from "Run-Time Configuration". But the idea of having GUCs that aren't documented at all, anywhere, is a very anti-Open Source idea. -- -Josh BerkusAglio Database SolutionsSan Francisco
Okay, separate documentation might work ;-) Jan Josh Berkus wrote: > Jan, > >> No, not documenting it IS a good move. > > I couldn't disagree more. Undocumented options? Who are we, Microsoft? > >> If there's a button people will >> press it, if there's a switch people will turn it on and if there's a >> slot people will stick in whatever they have ... believe it or not, I >> have found a Xmas cookie in the floppy drive of a consultant's notebook > <snip> > > These kinds of people don't read the documentation in the first place, so > we're in no danger from them. > > I can definitely see an argument that the "developer" switches should be > documented on a different page of the docs from "Run-Time Configuration". > But the idea of having GUCs that aren't documented at all, anywhere, is a > very anti-Open Source idea. > -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
One issue is that these settings don't even exist in most builds unless you add compiler flags. --------------------------------------------------------------------------- Josh Berkus wrote: > Jan, > > > No, not documenting it IS a good move. > > I couldn't disagree more. Undocumented options? Who are we, Microsoft? > > > If there's a button people will > > press it, if there's a switch people will turn it on and if there's a > > slot people will stick in whatever they have ... believe it or not, I > > have found a Xmas cookie in the floppy drive of a consultant's notebook > <snip> > > These kinds of people don't read the documentation in the first place, so > we're in no danger from them. > > I can definitely see an argument that the "developer" switches should be > documented on a different page of the docs from "Run-Time Configuration". > But the idea of having GUCs that aren't documented at all, anywhere, is a > very anti-Open Source idea. > > -- > -Josh Berkus > Aglio Database Solutions > San Francisco > > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Tom, I'm noticing re-namining of a lot of GUCs. As far as I can tell, the re-naming is based on logical reasons -- for example, "log_hostname" is more accurate that "hostname_lookup" -- but was a little surprised. We'd better warn users who are upgrading .... -- -Josh BerkusAglio Database SolutionsSan Francisco
Tom, Also, Autocommit seems to be gone from postgresql.conf.sample. Was this intentional? -- -Josh BerkusAglio Database SolutionsSan Francisco
Josh Berkus <josh@agliodbs.com> writes:
> Also, Autocommit seems to be gone from postgresql.conf.sample. Was this
> intentional?
Yes. It's toast ... didn't you see that flamewar a couple months ago?
regards, tom lane
Tom, > Yes. It's toast ... didn't you see that flamewar a couple months ago? Nope, missed it. There's enough traffic on this list that I ignore anything that I'm not working on. So are we eliminating the autocommit GUC entirely, or just from postgresql.conf? (I never used the setting, myself ...) -- -Josh BerkusAglio Database SolutionsSan Francisco
Josh Berkus <josh@agliodbs.com> writes:
> So are we eliminating the autocommit GUC entirely, or just from
> postgresql.conf?
Entirely --- putting it on the server side was a bad mistake, in
hindsight. The functionality is better provided on the client side.
(The GUC var does still physically exist, but that's only so that
commands like "SET AUTOCOMMIT TO ON" will be accepted from 7.3-vintage
clients. If you try "SET AUTOCOMMIT TO OFF" you'll get an error.
I'm unsure whether this needs to be in the documentation at all,
but it definitely doesn't need to be in postgresql.conf.sample.)
regards, tom lane
> So are we eliminating the autocommit GUC entirely, or just from > postgresql.conf? It's a client side feature now. Completely gone from the server. -- Rod Taylor <rbt@rbt.ca> PGP Key: http://www.rbt.ca/rbtpub.asc