Re: [HACKERS] Proposal to Re-Order Postgresql.Conf, part II
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
[EMAIL PROTECTED] | (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.c28 May 2003 18:19:09 - 1.127
--- src/backend/utils/misc/guc.c2 Jun 2003 16:03:20 -
***
*** 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 -
1.78
--- src/backend/utils/misc/postgresql.conf.sample 2 Jun 2003 16:03:20 -
***
*** 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
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Proposal to Re-Order Postgresql.Conf, part II
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 [EMAIL PROTECTED] | (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
Re: [HACKERS] Proposal to Re-Order Postgresql.Conf, part II
On Mon, 9 Jun 2003, Tom Lane wrote: Josh Berkus [EMAIL PROTECTED] 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
Re: [HACKERS] Proposal to Re-Order Postgresql.Conf, part II
Nigel J. Andrews wrote: On Mon, 9 Jun 2003, Tom Lane wrote: Josh Berkus [EMAIL PROTECTED] 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 [EMAIL PROTECTED] | (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? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Proposal to Re-Order Postgresql.Conf, part II
Justin Clift wrote: Tom Lane wrote: Josh Berkus [EMAIL PROTECTED] 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. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Proposal to Re-Order Postgresql.Conf, part II
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
Re: [HACKERS] Proposal to Re-Order Postgresql.Conf, part II
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. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Proposal to Re-Order Postgresql.Conf, part II
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 Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Proposal to Re-Order Postgresql.Conf, part II
Tom, 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 [EMAIL PROTECTED])
Re: [HACKERS] Proposal to Re-Order Postgresql.Conf, part II
Josh Berkus [EMAIL PROTECTED] 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 [EMAIL PROTECTED])
Re: [HACKERS] Proposal to Re-Order Postgresql.Conf, part II
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 Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Proposal to Re-Order Postgresql.Conf, part II
Josh Berkus [EMAIL PROTECTED] 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 [EMAIL PROTECTED])
Re: [HACKERS] Proposal to Re-Order Postgresql.Conf, part II
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 [EMAIL PROTECTED] PGP Key: http://www.rbt.ca/rbtpub.asc signature.asc Description: This is a digitally signed message part
Re: [HACKERS] Proposal to Re-Order Postgresql.Conf, part II
Robert Treat [EMAIL PROTECTED] 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? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Proposal to Re-Order Postgresql.Conf, part II
Josh Berkus [EMAIL PROTECTED] 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
Re: [HACKERS] Proposal to Re-Order Postgresql.Conf, part II
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 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Proposal to Re-Order Postgresql.Conf, part II
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 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 [EMAIL PROTECTED])
Re: [HACKERS] Proposal to Re-Order Postgresql.Conf, part II
Tom Lane wrote: Josh Berkus [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Proposal to Re-Order Postgresql.Conf, part II
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 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 #RESOURCE USAGE (except WAL) #Memory shared_buffers sort_mem vacuum_mem #Free Space Map max_fsm_pages max_fsm_relations #Disk Usage max_files_per_process #WRITE AHEAD LOG fsync wal_sync_method wal_buffers checkpoint_segments checkpoint_timeout checkpoint_warning commit_delay commit_siblings #QUERY TUNING #Planner Method Enabling enable_hashagg enable_hashjoin enable_indexscan enable_mergejoin enable_nestloop enable_seqscan enable_sort enable_tidscan #Planner Cost Constants effective_cache_size random_page_cost cpu_tuple_cost cpu_index_tuple_cost cpu_operator_cost default_statistics_target #Genetic Estimate Query Optimizer geqo geqo_threshold geqo_selection_bias geqo_pool_size geqo_effort geqo_generations geqo_random_seed #Other Query Modifiers explain_pretty_print from_collapse_limit join_collapse_limit max_expr_depth #CLIENT CONNECTION DEFAULTS #Statement Behaviour autocommit search_path default_transaction_isolation default_transaction_read_only statement_timeout #Locale and Formatting client_encoding australian_timezones datestyle timezone lc_messages lc_monetary lc_time lc_numeric #Other Defaults dynamic_library_path password_encryption #LOGGING DEBUGGING #Debugging/Logging Levels server_min_messages client_min_messages log_min_error_statement debug_print_parse debug_print_rewritten debug_print_plan debug_pretty_print debug_assertions silent_mode #Additional Info to Log log_connections log_duration log_pid log_statement log_timestamp hostname_lookup show_source_port #Syslog syslog syslog_facility syslog_ident #STATISTICS #Statistics monitoring show_parser_stats show_planner_stats show_executor_stats show_statement_stats #Query/Index Statistics Collector stats_start_collector stats_reset_on_server_start stats_command_string stats_row_level stats_block_level #LOCK MANAGEMENT deadlock_timeout max_locks_per_transaction #VERSION/PLATFORM COMPATIBILITY
Re: [HACKERS] Proposal to Re-Order Postgresql.Conf, part II
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 [EMAIL PROTECTED] PGP Key: http://www.rbt.ca/rbtpub.asc signature.asc Description: This is a digitally signed message part
Re: [HACKERS] Proposal to Re-Order Postgresql.Conf, part II
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 Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Proposal to Re-Order Postgresql.Conf, part II
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
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [HACKERS] Proposal to Re-Order Postgresql.Conf, part II
Josh Berkus [EMAIL PROTECTED] 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 [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Proposal to Re-Order Postgresql.Conf, part II
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
[EMAIL PROTECTED] | (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?
http://archives.postgresql.org
Re: [HACKERS] Proposal to Re-Order Postgresql.Conf, part II
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
Re: [HACKERS] Proposal to Re-Order Postgresql.Conf, part II
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 [EMAIL PROTECTED] PGP Key: http://www.rbt.ca/rbtpub.asc signature.asc Description: This is a digitally signed message part
Re: [HACKERS] Proposal to Re-Order Postgresql.Conf, part II
Josh Berkus [EMAIL PROTECTED] 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
