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
#CONNECTIONS AND AUTHENTICATION #Connection Settings tcpip_socket max_connections superuser_reserved_connections port unix_socket_directory unix_socket_group unix_socket_permissions #Security & Authentication ssl authentication_timeout virtual_host krb_server_keyfile db_user_namespace
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 Berkus Aglio Database Solutions San Francisco
---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
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!
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
---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
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?
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
---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ?
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?>
-- 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
---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives?
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
---------------------------(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
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?> >
---------------------------(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
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
---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ?
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
---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
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 Berkus Aglio Database Solutions San Francisco
---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
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
---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
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 Berkus Aglio Database Solutions San Francisco
---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives?
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 Berkus Aglio Database Solutions San Francisco
#CONNECTIONS AND AUTHENTICATION #Connection Settings tcpip_socket max_connections superuser_reserved_connections port unix_socket_directory unix_socket_group unix_socket_permissions #Security & Authentication authentication_timeout ssl krb_server_keyfile virtual_host db_user_namespace
---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
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
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, Pennsylvania 19073
---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
Nigel J. Andrews 10 June 2003 13:58:59 [ permanent link ]
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
---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
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.
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, Pennsylvania 19073
---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ?
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 "Developer Focused" 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 #
---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives?
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
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 #
---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
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, Pennsylvania 19073
---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
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 Berkus Aglio Database Solutions San Francisco
---------------------------(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
Also, Autocommit seems to be gone from postgresql.conf.sample. Was this intentional?
-- -Josh Berkus Aglio Database Solutions San Francisco
---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
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
---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
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 Berkus Aglio Database Solutions San Francisco
---------------------------(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
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
---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
