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 <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 Berkus
Aglio Database Solutions
San Francisco

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

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

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

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, Pennsylvania 19073

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 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

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

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 Berkus
Aglio Database Solutions
San Francisco

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 Berkus
Aglio Database Solutions
San Francisco

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

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

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, Pennsylvania 19073

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, Pennsylvania 19073

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 #

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

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, Pennsylvania 19073

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

Tom,

Also, Autocommit seems to be gone from postgresql.conf.sample. Was this
intentional?

--
-Josh Berkus
Aglio Database Solutions
San 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 Berkus
Aglio Database Solutions
San 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