Re: 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(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)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(at)commandprompt(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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?

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(at)commandprompt(dot)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(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)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(at)sss(dot)pgh(dot)pa(dot)us>
wrote:

> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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(at)postgresql(dot)org)
>

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler(at)lerctr(dot)org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)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(at)Yahoo(dot)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 bad
>
> Usually 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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Tom 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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> 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.

This strikes me as a completely arbitrary set of changes in
long-established behavior. People who want to turn off optimization
already know how to do it, and people who want asserts already know
how to do that. Eliminating the functional difference between these
--enable options isn't a step forward.

regards, tom lane

On Tue, Oct 28, 2003 at 01:09:36AM -0500, Bruce Momjian wrote:
> 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?

Maybe this is something to point out in the upgrading documents since
that way it seems it could be put off to the next release? It sure
sounds like a feature, and one about which there still seems to be
fair disagreement. It would indeed be nice, but it doesn't sound
like a show stopper to me if the proposal doesn't have anyone turning
up with the code to back it.

A

--
----
Andrew Sullivan 204-4141 Yonge Street
Afilias Canada Toronto, Ontario Canada
<andrew(at)libertyrms(dot)info> M2P 2A8
+1 416 646 3304 x110

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > 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.
>
> This strikes me as a completely arbitrary set of changes in
> long-established behavior. People who want to turn off optimization
> already know how to do it, and people who want asserts already know

How do you do it? CFLAGS="" configure?

> how to do that. Eliminating the functional difference between these
> --enable options isn't a step forward.

I was looking for something that would be a middle ground, and I thought
a super-debug binary might to it. I do think we should consider -g3 for
gcc. I didn't know it existed, and it does seem nice.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Tom Lane wrote:
>> This strikes me as a completely arbitrary set of changes in
>> long-established behavior. People who want to turn off optimization
>> already know how to do it, and people who want asserts already know

> How do you do it? CFLAGS="" configure?

I'd do CFLAGS="-O0" configure, but the other might work too. I think at
one point the autoconf code treated empty CFLAGS as being unset, but we
might have fixed that.

>> how to do that. Eliminating the functional difference between these
>> --enable options isn't a step forward.

> I was looking for something that would be a middle ground, and I thought
> a super-debug binary might to it. I do think we should consider -g3 for
> gcc. I didn't know it existed, and it does seem nice.

The argument in favor of adding -g by default for gcc is based in very
large part on the assumption that it doesn't cost any performance.
Changing --enable-debug so that it *does* cost performance (by
suppressing optimization) isn't a "middle ground"; it turns the switch
into something useful only for developers, and guarantees that no binary
used in the field will ever have debug info. I don't think we want that.

My experience is that debugging optimized code is not as hard as you
make it out to be --- I normally build with -O1 or -O2, because -O0 code
has awful performance on HPPA. Only rarely will I recompile -O0 because
I can't follow what's happening in a particular section of code.

I'm not sure about -g3; how much does it bloat the executable? Does it
work in every version of gcc?

regards, tom lane

On Tue, 2003-10-28 at 10:01, Bruce Momjian wrote:
> 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.

Why does '--name=value' suffice as documentation for
'--describe-config'? I think you should add '--describe-config' to the
syntax description at the top.

-Neil

Neil Conway wrote:
> On Tue, 2003-10-28 at 10:01, Bruce Momjian wrote:
> > 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.
>
> Why does '--name=value' suffice as documentation for
> '--describe-config'? I think you should add '--describe-config' to the
> syntax description at the top.

OK, but it is going to look kind of big up there and isn't of general
usefulness. Still want it?

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Andrew Sullivan wrote:

> On Tue, Oct 28, 2003 at 01:09:36AM -0500, Bruce Momjian wrote:
>> 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?
>
> Maybe this is something to point out in the upgrading documents since
> that way it seems it could be put off to the next release? It sure
> sounds like a feature, and one about which there still seems to be
> fair disagreement. It would indeed be nice, but it doesn't sound
> like a show stopper to me if the proposal doesn't have anyone turning
> up with the code to back it.

It has to be put into the docs either way, as there still IS sort of a
possibility for the DBA to get the data in without being checked.

Version 7.4 pg_dump still has the --disable-triggers option, which only
works for data-only dumps. So if someone want's to upgrade without
running fkey checks

v74/bin/pg_dump -d $dbname >$dbname.schema.sql
v74/bin/pg_dump -a --disable-triggers $dbname >$dbname.data.sql

then install 7.4, initdb and let psql slurp it up. It will loose some
performance because of building the indexes during data load instead of
CREATE INDEX after it. But I think it's still better than combing
through millions of fkey references.

Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #

On Tue, 2003-10-28 at 12:57, Bruce Momjian wrote:
> OK, but it is going to look kind of big up there and isn't of general
> usefulness. Still want it?

Well, as a matter of principle, I think it belongs there: if it's a
command-line option, it should be documented in the section that claims
to document the syntax of the command-line options. That said, I'm not
militant about it...

-Neil

Neil Conway wrote:
> On Tue, 2003-10-28 at 12:57, Bruce Momjian wrote:
> > OK, but it is going to look kind of big up there and isn't of general
> > usefulness. Still want it?
>
> Well, as a matter of principle, I think it belongs there: if it's a
> command-line option, it should be documented in the section that claims
> to document the syntax of the command-line options. That said, I'm not
> militant about it...

Added. Thanks.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

OK, doesn't look like we are going to add the ability to turn off
constraint checking for reload, nor add ANALYZE as part of ALTER TABLE
ADD FOREIGN KEY, so we only have a few items left.

I think we are nearing the conclusion that --enable-debug is OK now (no
-g without it), so the only remaining big item is the renaming of
check_function_bodies.

---------------------------------------------------------------------------

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
-------
Rename dump GUC variable to be more generic
Have gcc use -g, add --disable-debug, rename?

Documentation Changes
---------------------

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

> OK, doesn't look like we are going to add the ability to turn off
> constraint checking for reload, nor add ANALYZE as part of ALTER TABLE
> ADD FOREIGN KEY, so we only have a few items left.

Hey - what about if you just delete the pg_constraint entries for all
your foreign keys, then won't they all be dumped as CREATE CONSTRAINT
TRIGGERs?

Then, after restore, you can just re-run contrib/adddepend?

Chris

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
>>> We only have a few open items left. Can we finish them so we can move
>>> toward final release?

The list seems to be nearly down to this:

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

Given the apparent lack of interest in this topic, I propose that we
just leave the variable name as-is.

regards, tom lane