Thread: Open items
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
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
> 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
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) >
> > 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
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 >
> > 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
> 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
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 ...
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 ==========================================================================
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 ...
> 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
"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
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 ...
> > 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
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
> * 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
> 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
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
> > * 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
----- 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
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
> 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
> 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
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
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
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