Thread: Open items

Open items

From
Bruce Momjian
Date:
You can see that we have very few open items and beta2 has generated no
serious problems since its release on Wednesday.  Should we consider a
date for RC1?

Items postponed for 7.3 are at:
http://candle.pha.pa.us/cgi-bin/pgpatches2


---------------------------------------------------------------------------
                             P O S T G R E S Q L
                         7 . 2  O P E N    I T E M S


Current at ftp://candle.pha.pa.us/pub/postgresql/open_items.

* ALL ITEMS ARE COMPLETED *

Source Code Changes
-------------------
Compile in syslog feature by default? (Peter, Tom)
AIX compile (Tatsuo)
ecpg patches from Christof (Michael)

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


--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


Re: Open items

From
Tom Lane
Date:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> You can see that we have very few open items

Now that we have a test case for Warren Volz' problem (which I think is
the same thing that Barry Lind reported a week ago), I consider it a
"must fix" for 7.2.  No time estimate yet.
        regards, tom lane


Re: Open items

From
Bruce Momjian
Date:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > You can see that we have very few open items
> 
> Now that we have a test case for Warren Volz' problem (which I think is
> the same thing that Barry Lind reported a week ago), I consider it a
> "must fix" for 7.2.  No time estimate yet.

Agreed.  I was just giving everyone a _heads-up_ that we may be close to
RC1.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


Re: Open items

From
"Marc G. Fournier"
Date:
Earliest RC1 will be is Dec 1st ...

On Mon, 12 Nov 2001, Bruce Momjian wrote:

> > Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > > You can see that we have very few open items
> >
> > Now that we have a test case for Warren Volz' problem (which I think is
> > the same thing that Barry Lind reported a week ago), I consider it a
> > "must fix" for 7.2.  No time estimate yet.
>
> Agreed.  I was just giving everyone a _heads-up_ that we may be close to
> RC1.
>
> --
>   Bruce Momjian                        |  http://candle.pha.pa.us
>   pgman@candle.pha.pa.us               |  (610) 853-3000
>   +  If your life is a hard drive,     |  830 Blythe Avenue
>   +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
>



Re: Open items

From
Bruce Momjian
Date:
> 
> Earliest RC1 will be is Dec 1st ...

And you get that date from where?  We haven't even discussed it.

I am not saying it is a bad date, but it seems we should poll people
first to see when they want it.

When do people want RC1?  Let's hear from you.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


Re: Open items

From
"Marc G. Fournier"
Date:
Not sure which part you mis-understod ... I said "Earliest RC1", not "RC1
will be" ... there will be a Beta3 before RC1, today is the 13th, and Tom
Lane doesn't have a fix ready for what he's workin on ...

Giving Tom a couple of days, then figuring at least a week for Beta3 to be
out the door, we're looking at the earliest possible RC1 being Dec 1st ...

Its not a matter of when ppl want RC1 ... its a matter of whe RC1 is
deemed ready ... its not something to vote or poll ppl about, but thanks
for the attempt ...

On Tue, 13 Nov 2001, Bruce Momjian wrote:

> >
> > Earliest RC1 will be is Dec 1st ...
>
> And you get that date from where?  We haven't even discussed it.
>
> I am not saying it is a bad date, but it seems we should poll people
> first to see when they want it.
>
> When do people want RC1?  Let's hear from you.
>
> --
>   Bruce Momjian                        |  http://candle.pha.pa.us
>   pgman@candle.pha.pa.us               |  (610) 853-3000
>   +  If your life is a hard drive,     |  830 Blythe Avenue
>   +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026
>



Re: Open items

From
Bruce Momjian
Date:
> 
> Not sure which part you mis-understod ... I said "Earliest RC1", not "RC1
> will be" ... there will be a Beta3 before RC1, today is the 13th, and Tom
> Lane doesn't have a fix ready for what he's workin on ...
> 
> Giving Tom a couple of days, then figuring at least a week for Beta3 to be
> out the door, we're looking at the earliest possible RC1 being Dec 1st ...
> 
> Its not a matter of when ppl want RC1 ... its a matter of whe RC1 is
> deemed ready ... its not something to vote or poll ppl about, but thanks
> for the attempt ...

I personally think RC1 can happen before December 1.  That was my point.

I also am not sure if we need a beta3 seeing how few problems there were
with beta2.  But again, I am interested in what others say.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


Re: Open items

From
Bruce Momjian
Date:
> Looking at the number of commits that went on in the past couple of days,
> I won't put out an RC1 without a Beta3 to make sure that all potential
> bugs are covered over ... looking at a calender, though ... December 1st
> *might* be doable ...

Sorry.  I didn't mean to push you.  If you are very busy now and
after December 1 is better for you, that is fine.

> figure Beta3 the end of this week, depending on Tom's luck with that bug
> he's working on ... all goes smooth with Beta3, you may be right and we

Actually, I thought he had that fixed, or is it a different one.  If it
is the one I am thinking of, he sent a bug fix to the user, the user
confirmed it was fixed, and he committed the fix to CVS.

> could get a Rc1 packaged for the end of next week ... I gotta start
> looking at calender's more often ...

Let's see what Tom says.  Maybe he or others want more time as you
suggested.

> Alot depends on feedback on Beta3 ... and considering that there has been
> more feedback so far with Beta2 then there was with Beta1, I still
> wouldn't hold my breath for Dec 1st, but it is conceivable ...

Sure.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


Re: Open items

From
"Marc G. Fournier"
Date:
On Tue, 13 Nov 2001, Bruce Momjian wrote:

> >
> > Not sure which part you mis-understod ... I said "Earliest RC1", not "RC1
> > will be" ... there will be a Beta3 before RC1, today is the 13th, and Tom
> > Lane doesn't have a fix ready for what he's workin on ...
> >
> > Giving Tom a couple of days, then figuring at least a week for Beta3 to be
> > out the door, we're looking at the earliest possible RC1 being Dec 1st ...
> >
> > Its not a matter of when ppl want RC1 ... its a matter of whe RC1 is
> > deemed ready ... its not something to vote or poll ppl about, but thanks
> > for the attempt ...
>
> I personally think RC1 can happen before December 1.  That was my point.
>
> I also am not sure if we need a beta3 seeing how few problems there were
> with beta2.  But again, I am interested in what others say.

Looking at the number of commits that went on in the past couple of days,
I won't put out an RC1 without a Beta3 to make sure that all potential
bugs are covered over ... looking at a calender, though ... December 1st
*might* be doable ...

figure Beta3 the end of this week, depending on Tom's luck with that bug
he's working on ... all goes smooth with Beta3, you may be right and we
could get a Rc1 packaged for the end of next week ... I gotta start
looking at calender's more often ...

Alot depends on feedback on Beta3 ... and considering that there has been
more feedback so far with Beta2 then there was with Beta1, I still
wouldn't hold my breath for Dec 1st, but it is conceivable ...




Re: Open items

From
Vince Vielhaber
Date:
On Tue, 13 Nov 2001, Bruce Momjian wrote:

> >
> > Earliest RC1 will be is Dec 1st ...
>
> And you get that date from where?  We haven't even discussed it.
>
> I am not saying it is a bad date, but it seems we should poll people
> first to see when they want it.
>
> When do people want RC1?  Let's hear from you.

I think he's trying to tell you he won't be ready to do one till at least
then, not that that's the date.

Vince.
-- 
==========================================================================
Vince Vielhaber -- KA8CSH    email: vev@michvhf.com    http://www.pop4.net        56K Nationwide Dialup from $16.00/mo
atPop4 Networking       Online Campground Directory    http://www.camping-usa.com      Online Giftshop Superstore
http://www.cloudninegifts.com
==========================================================================





Re: Open items

From
"Marc G. Fournier"
Date:
On Tue, 13 Nov 2001, Bruce Momjian wrote:

> > Looking at the number of commits that went on in the past couple of days,
> > I won't put out an RC1 without a Beta3 to make sure that all potential
> > bugs are covered over ... looking at a calender, though ... December 1st
> > *might* be doable ...
>
> Sorry.  I didn't mean to push you.  If you are very busy now and
> after December 1 is better for you, that is fine.

Nope, for some reason I thought Dec 1st was alot closer then it actually
is ...




Re: Open items

From
Bruce Momjian
Date:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > You can see that we have very few open items
> 
> Now that we have a test case for Warren Volz' problem (which I think is
> the same thing that Barry Lind reported a week ago), I consider it a
> "must fix" for 7.2.  No time estimate yet.

Woohoo, I used the recently fixed fts.postgresql.org and found the fix
Tom has made:

Patch:http://fts.postgresql.org/db/mw/msg.html?mid=1061120

User confirmed fix:
http://fts.postgresql.org/db/mw/msg.html?mid=1090491

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


Re: Open items

From
Tom Lane
Date:
"Marc G. Fournier" <scrappy@hub.org> writes:
> Not sure which part you mis-understod ... I said "Earliest RC1", not "RC1
> will be" ... there will be a Beta3 before RC1, today is the 13th, and Tom
> Lane doesn't have a fix ready for what he's workin on ...

?? If you're thinking about that EvalPlanQual-crash issue I was worried
about yesterday, that was yesterday ;-).  It's fixed.

We do need a beta3, but I'd offer that we could put that out late this
week and plan for RC1 right after Thanksgiving holiday (ie, around 26
Nov, for the non-Americans on the list).

So far this has been a *very* quiet beta cycle, so I don't see a reason
not to be aggressive on the schedule.  We can always slip if problems
come up --- but if we're not seeing any problems, why wait?
        regards, tom lane


Re: Open items

From
"Marc G. Fournier"
Date:
On Tue, 13 Nov 2001, Tom Lane wrote:

> "Marc G. Fournier" <scrappy@hub.org> writes:
> > Not sure which part you mis-understod ... I said "Earliest RC1", not "RC1
> > will be" ... there will be a Beta3 before RC1, today is the 13th, and Tom
> > Lane doesn't have a fix ready for what he's workin on ...
>
> ?? If you're thinking about that EvalPlanQual-crash issue I was worried
> about yesterday, that was yesterday ;-).  It's fixed.

that was the one ...

> We do need a beta3, but I'd offer that we could put that out late this
> week and plan for RC1 right after Thanksgiving holiday (ie, around 26
> Nov, for the non-Americans on the list).

ya, after looking at a calender a bit more closely, I was starting to see
where Bruce's thoughts were coming from ...

Let's go for beta3 on Friday, and try for RC1 by the following Friday if
beta3 goes quiet ...




Re: Open items

From
Bruce Momjian
Date:
> > We do need a beta3, but I'd offer that we could put that out late this
> > week and plan for RC1 right after Thanksgiving holiday (ie, around 26
> > Nov, for the non-Americans on the list).
> 
> ya, after looking at a calender a bit more closely, I was starting to see
> where Bruce's thoughts were coming from ...
> 
> Let's go for beta3 on Friday, and try for RC1 by the following Friday if
> beta3 goes quiet ...

Sounds great!

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


Re: Open items

From
Peter Eisentraut
Date:
Bruce Momjian writes:

> Source Code Changes
> -------------------
> Compile in syslog feature by default? (Peter, Tom)

I consider this dead/postponed.

> AIX compile (Tatsuo)
> ecpg patches from Christof (Michael)

* The last message translations should be in before RC1.  Stuff that
doesn't compile at that time will be disabled.  I suggest that from now on
no more gratuitous "word smithing" in the C code, for the benefit of
translators -- most of our messages stink anyway, and they ain't getting
better with two more spaces in them.  ;-)

* Something needs to be done about the expected file for the geometry
test.  The standard file used to work on my system ever since I can
remember, but now something's changed (not my system).

The things is that the expected file was last changed without the input
file changing.  This must not happen, IMNSHO.


> Documentation Changes
> ---------------------

* Re-make key words table (tomorrow at the latest)

* Make man pages (I'll look at that over the weekend.  RC1 should be
considered reference page freeze so I can finalize them.)

-- 
Peter Eisentraut   peter_e@gmx.net



Re: Open items

From
Thomas Lockhart
Date:
> * Something needs to be done about the expected file for the geometry
> test.  The standard file used to work on my system ever since I can
> remember, but now something's changed (not my system).

I'll guess that the reference system has changed. I can't freeze my OS
at some 1996 (or 2000) vintage version to guarantee that results never
change. I went the last year or two with that geometry test failing for
me. I'm not sure what results I'd get with the latest glibc, but once I
upgrade we'll find out.

What system are you running for which you would expect an exact match of
test results in the transcendental functions?

> The things is that the expected file was last changed without the input
> file changing.  This must not happen, IMNSHO.

I had carefully inspected the differences (over and over and over) and
they were all trivial last-decimal-place kinds of things afaicr.
Actually, I'm responding here like I'm the one who made the change, but
I haven't gone back to the cvs logs to confirm that.
                    - Thomas


Re: Open items

From
Bruce Momjian
Date:
> Bruce Momjian writes:
>
> > Source Code Changes
> > -------------------
> > Compile in syslog feature by default? (Peter, Tom)
>
> I consider this dead/postponed.

OK, I will add it to TODO.

>
> > AIX compile (Tatsuo)

> > ecpg patches from Christof (Michael)

The ecpg was just applied so that is done.

>
> * The last message translations should be in before RC1.  Stuff that
> doesn't compile at that time will be disabled.  I suggest that from now on
> no more gratuitous "word smithing" in the C code, for the benefit of
> translators -- most of our messages stink anyway, and they ain't getting
> better with two more spaces in them.  ;-)

Agreed.

> * Something needs to be done about the expected file for the geometry
> test.  The standard file used to work on my system ever since I can
> remember, but now something's changed (not my system).
>
> The things is that the expected file was last changed without the input
> file changing.  This must not happen, IMNSHO.
>

Added to open items list.

>
> > Documentation Changes
> > ---------------------
>
> * Re-make key words table (tomorrow at the latest)
>
> * Make man pages (I'll look at that over the weekend.  RC1 should be
> considered reference page freeze so I can finalize them.)

Current open items list attached.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026
                              P O S T G R E S Q L

                          7 . 2  O P E N    I T E M S


Current at ftp://candle.pha.pa.us/pub/postgresql/open_items.

Source Code Changes
-------------------
Compile in syslog feature by default? (Peter, Tom)
AIX compile (Tatsuo)
Fix geometry expected files
Complete timestamp/current changes

Documentation Changes
---------------------
Update keywords table
Make manual pages

Re: Open items

From
Tom Lane
Date:
Peter Eisentraut <peter_e@gmx.net> writes:
> * Something needs to be done about the expected file for the geometry
> test.  The standard file used to work on my system ever since I can
> remember, but now something's changed (not my system).
> The things is that the expected file was last changed without the input
> file changing.  This must not happen, IMNSHO.

Lockhart has always taken the position that the regression reference
platform is whatever he's using ;-).  IIRC, he updated from Mandrake 7
to Mandrake 8, or something like that, over the summer, and voila the
reference geometry results changed.

You need to see if any of the existing variant files for geometry
match your platform, and if not make a new variant; in any case add
an entry to resultmap.

Of course the long-term answer here is to arrange to suppress a few
low-order digits when displaying the geometry results, but that's
not happening for 7.2.
        regards, tom lane


Re: Open items

From
Bruce Momjian
Date:
> > * The last message translations should be in before RC1.  Stuff that
> > doesn't compile at that time will be disabled.  I suggest that from now on
> > no more gratuitous "word smithing" in the C code, for the benefit of
> > translators -- most of our messages stink anyway, and they ain't getting
> > better with two more spaces in them.  ;-)
> 
> Agreed.

Or should I have said    "a  g r   e e     d."  :-)

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


Re: Open items

From
"Serguei Mokhov"
Date:
----- Original Message ----- 
From: Peter Eisentraut <peter_e@gmx.net>
Sent: Wednesday, November 14, 2001 11:24 AM

> * The last message translations should be in before RC1.

I'll try to finish up Russian translations of pg_dump
and fix the rest by Dec. 1.

--
Serguei A. Mokhov



Re: Open items

From
Bill Studenmund
Date:
On Wed, 14 Nov 2001, Thomas Lockhart wrote:

> What system are you running for which you would expect an exact match of
> test results in the transcendental functions?

I think the general point is that it'd be nice if regression tests didn't
report failure due to numerical noise. :-)

> > The things is that the expected file was last changed without the input
> > file changing.  This must not happen, IMNSHO.
>
> I had carefully inspected the differences (over and over and over) and
> they were all trivial last-decimal-place kinds of things afaicr.
> Actually, I'm responding here like I'm the one who made the change, but
> I haven't gone back to the cvs logs to confirm that.

Is there some way we can make the tests smart enough to only printout the
significant digits, so that if there is a difference, it is important?

Take care,

Bill



Re: Open items

From
Thomas Lockhart
Date:
> Is there some way we can make the tests smart enough to only printout the
> significant digits, so that if there is a difference, it is important?

Well, what we've avoided doing so far, on the assumption that we might
mask some subtle but important problem, is to run the select outputs
through a formatting function which strips off a few (in)significant
digits.

I'm not sure if to_char() can do the job (it seems to be oriented to
doing fixed-length fields) but if it can then we've got something usable
already.
                       - Thomas


Re: Open items

From
Bruce Momjian
Date:
> On Wed, 14 Nov 2001, Thomas Lockhart wrote:
> 
> > What system are you running for which you would expect an exact match of
> > test results in the transcendental functions?
> 
> I think the general point is that it'd be nice if regression tests didn't
> report failure due to numerical noise. :-)
> 

Added to TODO:

* Modify regression tests to prevent failures do to minor numeric rounding

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


Re: Open items

From
Peter Eisentraut
Date:
Bill Studenmund writes:

> I think the general point is that it'd be nice if regression tests didn't
> report failure due to numerical noise. :-)

Actually, I'm not convinced all of these are strictly numerical noise.
Differences in the 5th out of 10 decimal places or positive vs. negative
zero look more like "incorrect optimization" or "incomplete floating point
implementation".  It could be interesting to do these calculations
symbolically and run the final result to plenty of decimal places to see
who's right.

-- 
Peter Eisentraut   peter_e@gmx.net



Re: Open items

From
Peter Eisentraut
Date:
Thomas Lockhart writes:

> I'll guess that the reference system has changed. I can't freeze my OS
> at some 1996 (or 2000) vintage version to guarantee that results never
> change. I went the last year or two with that geometry test failing for
> me. I'm not sure what results I'd get with the latest glibc, but once I
> upgrade we'll find out.

I don't mind which system is the "reference" and which ones are
resultmap-enabled, since this is really only an implementation detail.
However, by changing the expected results of a test without the test input
changing, you implicitly deprecate all systems for which this test used to
pass, and there were plenty of them, otherwise we wouldn't have all those
Linux systems in the supported list.

Nevertheless, Mandrake is just about the last OS I would trust to be a
"reference" for floating point results.  I will point out that for me the
geometry test did not change when I updated from Red Hat 5.2 to 7.0, and
various other Linux distributions apparently accepted the previous results
as well.  Shades of -ffast-math come to mind...

-- 
Peter Eisentraut   peter_e@gmx.net



Re: Open items

From
Bill Studenmund
Date:
On Thu, 15 Nov 2001, Peter Eisentraut wrote:

> Bill Studenmund writes:
>
> > I think the general point is that it'd be nice if regression tests didn't
> > report failure due to numerical noise. :-)
>
> Actually, I'm not convinced all of these are strictly numerical noise.
> Differences in the 5th out of 10 decimal places or positive vs. negative
> zero look more like "incorrect optimization" or "incomplete floating point
> implementation".  It could be interesting to do these calculations
> symbolically and run the final result to plenty of decimal places to see
> who's right.

I think it would depend on where the result came from. I think the
problems the regression tests hit is that we subtract two nearly-equal
numbers. Like ones which were the same for say 7 of 15 digits. So the
answer we get is only significant to 8 digits, but the display code wants
to print 15. So we get seven digits of questionable lineage. I'm not sure
what the standards say should go into them.

Doing the calculation to "plenty" of decimal places would be really
interesting if we could then map the answer back to the number of bits in
the mantisa in the original number. But I'm not sure how to do that easily
in the regression test.

Take care,

Bill