Open items
We only have a few open items left. Can we finish them so we can move
toward final release?
---------------------------------------------------------------------------
P O S T G R E S Q L
7 . 4 O P E N I T E M S
Current at ftp://momjian.postgresql.org/pub/postgresql/open_items.
Changes
-------
Allow superuser (dba?) the ability to turn off foreign key checks/all
constraints/triggers, not settable from postgresql.conf?
Move ANALYZE before foreign key creation?
Rename dump GUC variable to be more generic
Document new --describe-config postgres option
Have gcc use -g, add --disable-debug, rename?
Documentation Changes
---------------------
--
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, 27 Oct 2003, Bruce Momjian wrote:
Changes
-------
Allow superuser (dba?) the ability to turn off foreign key checks/all
constraints/triggers, not settable from postgresql.conf?
feature, not bug fix, no?
Marc G. Fournier wrote:
On Mon, 27 Oct 2003, Bruce Momjian wrote:
Changes
-------
Allow superuser (dba?) the ability to turn off foreign key checks/all
constraints/triggers, not settable from postgresql.conf?feature, not bug fix, no?
It became important when everyone realized that 7.4 would be first major
upgrade with full foreign key checking --- prior to that we did CREATE
CONSTRAINT TRIGGER that didn't check data. Basically, that's how it got
on the open item list.
--
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
Hello,
Based on the current open items... when do we expect release?
Sincerely,
Joshua Drake
--
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-222-2783 - jd@commandprompt.com - http://www.commandprompt.com
Editor-N-Chief - PostgreSQl.Org - http://www.postgresql.org On Mon, 27 Oct 2003, Joshua D. Drake wrote:
Hello,
Based on the current open items... when do we expect release?
As soon as the items are fixed? :)
Marc G. Fournier wrote:
On Mon, 27 Oct 2003, Joshua D. Drake wrote:
Hello,
Based on the current open items... when do we expect release?
As soon as the items are fixed? :)
I am confused why we aren't wrapping up these items. I have waited for
the people who proposed these ideas to jump in and do them, but I might
start on them myself soon.
--
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 19073Hello,
Well the reason I brought it up was the rather interesting discussion
that Jan had today about Vacuum.
I was wondering if we were going to explore that before the 7.4 release?
Sincerely,
Joshua Drake
Bruce Momjian wrote:
Marc G. Fournier wrote:
On Mon, 27 Oct 2003, Joshua D. Drake wrote:
Hello,
Based on the current open items... when do we expect release?
As soon as the items are fixed? :)
I am confused why we aren't wrapping up these items. I have waited for
the people who proposed these ideas to jump in and do them, but I might
start on them myself soon.
--
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-222-2783 - jd@commandprompt.com - http://www.commandprompt.com
Editor-N-Chief - PostgreSQl.Org - http://www.postgresql.org Joshua D. Drake wrote:
Hello,
Well the reason I brought it up was the rather interesting discussion
that Jan had today about Vacuum.
I was wondering if we were going to explore that before the 7.4 release?
No, I am afraid we are way past time time for that kind of addition.
--
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, Oct 27, 2003 at 07:45:53PM -0800, Joshua D. Drake wrote:
Hello,
Well the reason I brought it up was the rather interesting discussion
that Jan had today about Vacuum.
I was wondering if we were going to explore that before the 7.4 release?
I would expect that to be left for 7.5 ... ?
--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
On Mon, 27 Oct 2003, Bruce Momjian wrote:
Marc G. Fournier wrote:
On Mon, 27 Oct 2003, Bruce Momjian wrote:
Changes
-------
Allow superuser (dba?) the ability to turn off foreign key checks/all
constraints/triggers, not settable from postgresql.conf?feature, not bug fix, no?
It became important when everyone realized that 7.4 would be first major
upgrade with full foreign key checking --- prior to that we did CREATE
CONSTRAINT TRIGGER that didn't check data. Basically, that's how it got
on the open item list.
Have we heard anything about whether this is still as important given
the other optimizations to the alter table case from people with large
enough data sets to notice?
On Mon, 27 Oct 2003, Bruce Momjian wrote:
Marc G. Fournier wrote:
On Mon, 27 Oct 2003, Bruce Momjian wrote:
Changes
-------
Allow superuser (dba?) the ability to turn off foreign key checks/all
constraints/triggers, not settable from postgresql.conf?feature, not bug fix, no?
It became important when everyone realized that 7.4 would be first major
upgrade with full foreign key checking --- prior to that we did CREATE
CONSTRAINT TRIGGER that didn't check data. Basically, that's how it got
on the open item list.
Altho important, it is still a feature, and as such, should not be
critical to holding up the release ...
Bruce Momjian <pgman@candle.pha.pa.us> writes:
We only have a few open items left. Can we finish them so we can move
toward final release?
Okay, here's my two cents:
Allow superuser (dba?) the ability to turn off foreign key checks/all
constraints/triggers, not settable from postgresql.conf?
We have seen a wide variety of proposals and opinions on this, ranging
from "you can turn off the C in ACID anytime you want" to "you can
suppress ALTER TABLE ADD FOREIGN KEY's cross-check ... and nothing else
... but only if you are superuser, mutter the right secret password, and
spin three times widdershins". I am in the "three times widdershins"
camp myself. But given the lack of consensus, I think the right
short-term answer is to do nothing further. We can improve this more
in future releases.
Move ANALYZE before foreign key creation?
"Move"? pg_dump scripts don't issue ANALYZE at all. Again, I think
this is not something to be introducing at the last minute.
Rename dump GUC variable to be more generic
Sure, if we can agree on a name.
Document new --describe-config postgres option
Go to it.
Have gcc use -g, add --disable-debug, rename?
Personally I don't like the idea of this behavior defaulting differently
depending on which compiler you use. I can see the practical arguments
for doing so, but it still rubs me the wrong way. Can anyone offer new
arguments pro or con here?
regards, tom lane
Marc G. Fournier wrote:
On Mon, 27 Oct 2003, Bruce Momjian wrote:
Marc G. Fournier wrote:
On Mon, 27 Oct 2003, Bruce Momjian wrote:
Changes
-------
Allow superuser (dba?) the ability to turn off foreign key checks/all
constraints/triggers, not settable from postgresql.conf?feature, not bug fix, no?
It became important when everyone realized that 7.4 would be first major
upgrade with full foreign key checking --- prior to that we did CREATE
CONSTRAINT TRIGGER that didn't check data. Basically, that's how it got
on the open item list.Altho important, it is still a feature, and as such, should not be
critical to holding up the release ...
That's all I need --- a consensus that is isn't significant enough to be
on this list.
--
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
what about my Privilege regression failure?
I'm not sure why it's dying...
LER
--On Monday, October 27, 2003 23:32:45 -0500 Tom Lane <tgl@sss.pgh.pa.us>
wrote:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
We only have a few open items left. Can we finish them so we can move
toward final release?Okay, here's my two cents:
Allow superuser (dba?) the ability to turn off foreign key checks/all
constraints/triggers, not settable from postgresql.conf?We have seen a wide variety of proposals and opinions on this, ranging
from "you can turn off the C in ACID anytime you want" to "you can
suppress ALTER TABLE ADD FOREIGN KEY's cross-check ... and nothing else
... but only if you are superuser, mutter the right secret password, and
spin three times widdershins". I am in the "three times widdershins"
camp myself. But given the lack of consensus, I think the right
short-term answer is to do nothing further. We can improve this more
in future releases.Move ANALYZE before foreign key creation?
"Move"? pg_dump scripts don't issue ANALYZE at all. Again, I think
this is not something to be introducing at the last minute.Rename dump GUC variable to be more generic
Sure, if we can agree on a name.
Document new --describe-config postgres option
Go to it.
Have gcc use -g, add --disable-debug, rename?
Personally I don't like the idea of this behavior defaulting differently
depending on which compiler you use. I can see the practical arguments
for doing so, but it still rubs me the wrong way. Can anyone offer new
arguments pro or con here?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)
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Tom Lane wrote:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
We only have a few open items left. Can we finish them so we can move
toward final release?Okay, here's my two cents:
Allow superuser (dba?) the ability to turn off foreign key checks/all
constraints/triggers, not settable from postgresql.conf?We have seen a wide variety of proposals and opinions on this, ranging
from "you can turn off the C in ACID anytime you want" to "you can
suppress ALTER TABLE ADD FOREIGN KEY's cross-check ... and nothing else
... but only if you are superuser, mutter the right secret password, and
spin three times widdershins". I am in the "three times widdershins"
camp myself. But given the lack of consensus, I think the right
short-term answer is to do nothing further. We can improve this more
in future releases.Move ANALYZE before foreign key creation?
"Move"? pg_dump scripts don't issue ANALYZE at all. Again, I think
this is not something to be introducing at the last minute.
I am grouping the above two items together --- I thought the idea was to
give people a way to load 7.4 in a fairly rapid manner --- we now have
the ability to do ALTER TABLE ADD CONSTRAINT, but it lacks ANALYZE
statistics, so it is kind of slow --- perhaps nothing can be done about
this. Should we try to gather some statistics before doing the ALTER
TABLE ADD CONSTRAINT queries if no stats exist? I am not advocating it,
but just asking. Should COPY update the row count? Would that help?
Also, if we want to improve this for 7.5, should we be modifying pg_dump
now to improve load times for later reloads? I think that was part of
the issue. Of course, we can do that in a minor release, but it is
better to hit it now.
Also, I find I use a lot of "---" in my emails because it seems the best
way to clearly communicate my intent, but I didn't realize how often I
am using sentence fragments. Hope that is OK with everyone. Full
sentences are so definate, while sentence fragments communicate the
uncertainty I have on many issues where I am looking for
concensus/opinions and don't want to state something in black and white.
Rename dump GUC variable to be more generic
Sure, if we can agree on a name.
We have a few options here. Currently it is "check_function_bodies".
The ideas where validation mode:
I think I'd prefer to keep foreign key check disabling separate. Or at
least make it separately selectable. Maybe validation_mode could have
multiple levels ("off", "safe", "risky")?
and an even more generic "restore_mode" where the restore_mode could
control even more things, such as doing an ANALYZE before an ALTER TABLE
ADD CONSTRAINT.
However, we also have the "check_constraints" floating out there that we
might add some day to disable constraints, so I can imagine us having
more than one knob to tune in restore situations.
What I am concerned about it adding "validation_mode" then needing to
add "restore_mode" later (for some other purpose) that will need to turn
off "validation_mode". In that case, we have conflicting GUC variables
and that is bad news.
After thinking for a while, I think validation is too important a
concept to be lumped into a restore_mode variable. Let's call it
validation_mode. Right now it controls only function bodies, but later
it can control constraint checking and perhaps other things, and of
course only for the super-user. It could have three values if you wish:
"off", "delay", and "on", where function bodies would really be a
"delay".
Document new --describe-config postgres option
Go to it.
OK, I will get on it --- I will just mention it and say it is mostly
useful for admin tools.
Have gcc use -g, add --disable-debug, rename?
Personally I don't like the idea of this behavior defaulting differently
depending on which compiler you use. I can see the practical arguments
for doing so, but it still rubs me the wrong way. Can anyone offer new
arguments pro or con here?
You and I think don't like the inconsistency, while Jan likes the debug
where ever possible (gcc). There were a few others who liked the debug
for gcc by default.
I think if folks are debugging, they probably should turn off
optimization anyway to make sense of the output, and we are never going
to ship without optimization. What might be nice would be for
--enable-debug to turn off optimization as well so people can actually
make sense of the code in the debugger.
Basically, I don't like the debug because of:
inconsistency with non-gcc
binary bloat
binary bloat encourages strip, which is really bad
Usually function names are enough for us to take a guess on the cause.
--
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 Tue, 2003-10-28 at 00:02, Bruce Momjian wrote:
Marc G. Fournier wrote:
On Mon, 27 Oct 2003, Bruce Momjian wrote:
Marc G. Fournier wrote:
On Mon, 27 Oct 2003, Bruce Momjian wrote:
Changes
-------
Allow superuser (dba?) the ability to turn off foreign key checks/all
constraints/triggers, not settable from postgresql.conf?feature, not bug fix, no?
It became important when everyone realized that 7.4 would be first major
upgrade with full foreign key checking --- prior to that we did CREATE
CONSTRAINT TRIGGER that didn't check data. Basically, that's how it got
on the open item list.Altho important, it is still a feature, and as such, should not be
critical to holding up the release ...That's all I need --- a consensus that is isn't significant enough to be
on this list.
Does this prevent me from recreating databases that might have improper
data in the foreign key fields? If i would have been able to upgrade
these database in all prior versions but will now be prevented from
upgrading, then this is really a bug fix imho.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
On Mon, Oct 27, 2003 at 11:32:45PM -0500, Tom Lane wrote:
Have gcc use -g, add --disable-debug, rename?
Personally I don't like the idea of this behavior defaulting differently
depending on which compiler you use. I can see the practical arguments
for doing so, but it still rubs me the wrong way. Can anyone offer new
arguments pro or con here?
Not an argument.. I use gcc, and I configure --enable-debug --enable-cassert.
I was surprised reading the discussion that the "--enable-debug" was
superfluous and thought it didn't "feel right"..
Cheers,
Patrick
Bruce Momjian wrote:
Joshua D. Drake wrote:
Hello,
Well the reason I brought it up was the rather interesting discussion
that Jan had today about Vacuum.
I was wondering if we were going to explore that before the 7.4 release?No, I am afraid we are way past time time for that kind of addition.
Couln't agree more.
We have absolutely no plan what kind of cache algorithm or strategy we
want as a replacement, what granularity of tuning options it might need
and what good defaults would be. This is the kind of stuff that looks
simple but needs a full development cycle like TOAST did.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
Bruce Momjian wrote:
Have gcc use -g, add --disable-debug, rename?
Personally I don't like the idea of this behavior defaulting differently
depending on which compiler you use. I can see the practical arguments
for doing so, but it still rubs me the wrong way. Can anyone offer new
arguments pro or con here?You and I think don't like the inconsistency, while Jan likes the debug
where ever possible (gcc). There were a few others who liked the debug
for gcc by default.I think if folks are debugging, they probably should turn off
optimization anyway to make sense of the output, and we are never going
to ship without optimization. What might be nice would be for
--enable-debug to turn off optimization as well so people can actually
make sense of the code in the debugger.Basically, I don't like the debug because of:
inconsistency with non-gcc
binary bloat
binary bloat encourages strip, which is really badUsually function names are enough for us to take a guess on the cause.
I think I have a compromise for --enable-debug: How about if
--enable-debug removes optimization, adds -g (or -g3 for macro debugging
symbols in gcc), and maybe even enables casserts. That way,
--enable-debug gives us a super-debuggable binary that we would never
ship by default. Also, I can add a section to the release notes that
discourages people running strip.
--
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 19073Tom Lane wrote:
Document new --describe-config postgres option
Go to it.
OK, that attached patch completes this item. I did not document
--describe-config at the top as an accepted arg, but there was already a
--name=value line.
I added it to the bottom of the "SEMI-INTERNAL OPTIONS" section.
--
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
