Horton

Thread

  1. Open items

    Bruce Momjian <pgman@candle.pha.pa.us> — 2003-10-28T02:38:45Z

    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

  2. Re: Open items

    Marc G. Fournier <scrappy@postgresql.org> — 2003-10-28T02:56:05Z

    
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?

  3. Re: Open items

    Bruce Momjian <pgman@candle.pha.pa.us> — 2003-10-28T03:13:16Z

    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

  4. Re: Open items

    Joshua D. Drake <jd@commandprompt.com> — 2003-10-28T03:30:23Z

    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

  5. Re: Open items

    Marc G. Fournier <scrappy@postgresql.org> — 2003-10-28T03:35:05Z

    
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? :)

  6. Re: Open items

    Bruce Momjian <pgman@candle.pha.pa.us> — 2003-10-28T03:40:38Z

    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 19073

  7. Re: Open items

    Joshua D. Drake <jd@commandprompt.com> — 2003-10-28T03:45:53Z

    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@commandprompt.com - http://www.commandprompt.com
Editor-N-Chief - PostgreSQl.Org - http://www.postgresql.org

  8. Re: Open items

    Bruce Momjian <pgman@candle.pha.pa.us> — 2003-10-28T03:48:58Z

    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

  9. Re: Open items

    Alvaro Herrera <alvherre@dcc.uchile.cl> — 2003-10-28T03:50:22Z

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

  10. Re: Open items

    Stephan Szabo <sszabo@megazone.bigpanda.com> — 2003-10-28T04:04:04Z

    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?

  11. Re: Open items

    Marc G. Fournier <scrappy@postgresql.org> — 2003-10-28T04:28:00Z

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

  12. Re: Open items

    Tom Lane <tgl@sss.pgh.pa.us> — 2003-10-28T04:32:45Z

    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

  13. Re: Open items

    Bruce Momjian <pgman@candle.pha.pa.us> — 2003-10-28T05:02:01Z

    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

  14. Re: Open items

    Larry Rosenman <ler@lerctr.org> — 2003-10-28T05:43:57Z

    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

  15. Re: Open items

    Bruce Momjian <pgman@candle.pha.pa.us> — 2003-10-28T06:09:36Z

    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

  16. Re: Open items

    Robert Treat <xzilla@users.sourceforge.net> — 2003-10-28T13:21:37Z

    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

  17. Re: Open items

    Patrick Welche <prlw1@newn.cam.ac.uk> — 2003-10-28T13:54:54Z

    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

  18. Re: Open items

    Jan Wieck <janwieck@yahoo.com> — 2003-10-28T13:56:56Z

    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 #

  19. Re: Open items

    Bruce Momjian <pgman@candle.pha.pa.us> — 2003-10-28T14:00:26Z

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

  20. Re: Open items

    Bruce Momjian <pgman@candle.pha.pa.us> — 2003-10-28T15:01:13Z

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

  21. Re: Open items

    Tom Lane <tgl@sss.pgh.pa.us> — 2003-10-28T15:11:37Z

    Bruce Momjian <pgman@candle.pha.pa.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

  22. Re: Open items

    Andrew Sullivan <andrew@libertyrms.info> — 2003-10-28T15:16:23Z

    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@libertyrms.info>                              M2P 2A8
                                         +1 416 646 3304 x110

  23. Re: Open items

    Bruce Momjian <pgman@candle.pha.pa.us> — 2003-10-28T15:22:47Z

    Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.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@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

  24. Re: Open items

    Tom Lane <tgl@sss.pgh.pa.us> — 2003-10-28T16:16:27Z

    Bruce Momjian <pgman@candle.pha.pa.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

  25. Re: Open items

    Neil Conway <neilc@samurai.com> — 2003-10-28T16:32:39Z

    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

  26. Re: Open items

    Bruce Momjian <pgman@candle.pha.pa.us> — 2003-10-28T17:57:40Z

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

  27. Re: Open items

    Jan Wieck <janwieck@yahoo.com> — 2003-10-28T18:51:57Z

    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@Yahoo.com #

  28. Re: Open items

    Neil Conway <neilc@samurai.com> — 2003-10-28T18:58:06Z

    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

  29. Re: Open items

    Bruce Momjian <pgman@candle.pha.pa.us> — 2003-10-28T19:39:26Z

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

  30. Re: Open items

    Bruce Momjian <pgman@candle.pha.pa.us> — 2003-10-28T19:41:59Z

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

  31. Re: Open items

    Christopher Kings-Lynne <chriskl@familyhealth.com.au> — 2003-10-29T01:51:27Z

    > 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

  32. Re: Open items

    Tom Lane <tgl@sss.pgh.pa.us> — 2003-10-30T23:16:20Z

    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?

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