Thread: v6.3 release ToDo list and supported ports
Bruce, are you planning on keeping a ToDo list for the 6.3 release as you have in (at least) the past few releases? That will make sure that we don't leave something out. As a start: Commit sgml document sources(Thomas) Commit html documents(Thomas) Commit postscript documents(Thomas) Fix aggregates in views reported by Brett Include subselect regression tests(Thomas, unless someone else wants it :) Fix crashes from backend collisions reported by Tom H. Fix isinf.c irix port problem reported by Andrew(Marc) Check triggers regression test(Vadim) Check select_views regression test Test ecpg new struct features(Michael) Test big-endian/little-endian operation(Tatsuo?) I don' know if we need this... Confirm ports for v6.3 (need this soon for docs): _ aix4.2 - already fixed? what are actual versions?? _ aix3.5 _ bsdi _ freebsd,etc (I don't know the different bsd variants) _ 68k/bsdXXX (Macintosh port) never successful? Needed 68k locking code?? _ dgux _ hpux9.0.x _ hpux10.20 _ alpha/unix - currently broken? _ alpha/linux - currently broken? _ ppc/mklinux(Tatsuo?) * ix86/linux(Thomas) - confirmed working _ ix86/solaris _ irix5 _ irix6 _ nextstep - not tested? not working?? _ sco _ sparc/solaris _ sparc/sunos _ svr4(which platforms?) _ ultrix4 _ univel If a platform does not get on this list, and have a confirmed compile/regression test, then it will go on the unsupported list for v6.3 :( The regression tests do not have to pass completely (since there are a couple of remaining beta problems) but the port should compile, run, and produce reasonable results for most tests. Can people commit to checking on each platform? (I know some have been done already...)
Is the ix86/linux "confirmed" port using libc 5 or glibc 2.x (aka libc6)? As most major distributions are going to release all new versions with glibc I think it's prudent to test on both "platforms" independantly. -Fred > Bruce, are you planning on keeping a ToDo list for the 6.3 release > as you have in (at least) the past few releases? That will make sure > that we don't leave something out. As a start: > > Commit sgml document sources(Thomas) > Commit html documents(Thomas) > Commit postscript documents(Thomas) > Fix aggregates in views reported by Brett > Include subselect regression tests(Thomas, unless someone else wants > it :) Fix crashes from backend collisions reported by Tom H. Fix > isinf.c irix port problem reported by Andrew(Marc) Check triggers > regression test(Vadim) Check select_views regression test Test ecpg > new struct features(Michael) Test big-endian/little-endian > operation(Tatsuo?) I don' know if we need this... > > Confirm ports for v6.3 (need this soon for docs): > > _ aix4.2 - already fixed? what are actual versions?? > _ aix3.5 > _ bsdi > _ freebsd,etc (I don't know the different bsd variants) > _ 68k/bsdXXX (Macintosh port) never successful? Needed 68k locking > code?? _ dgux _ hpux9.0.x _ hpux10.20 _ alpha/unix - currently > broken? _ alpha/linux - currently broken? _ ppc/mklinux(Tatsuo?) > * ix86/linux(Thomas) - confirmed working > _ ix86/solaris > _ irix5 > _ irix6 > _ nextstep - not tested? not working?? > _ sco > _ sparc/solaris > _ sparc/sunos > _ svr4(which platforms?) > _ ultrix4 > _ univel > > If a platform does not get on this list, and have a confirmed > compile/regression test, then it will go on the unsupported list for > v6.3 :( The regression tests do not have to pass completely (since > there are a couple of remaining beta problems) but the port should > compile, run, and produce reasonable results for most tests. > > Can people commit to checking on each platform? (I know some have > been done already...) > >
> Is the ix86/linux "confirmed" port using libc 5 or glibc 2.x (aka
> libc6)? As most major distributions are going to release all new
> versions with glibc I think it's prudent to test on both "platforms"
> independently.
Yes, that is a good point. There is a known bug in the glibc2 math
library which breaks the date/time routines:
select '4 hours'::timespan;
---------
@ 4 hours
(1 row)
comes out instead as
tgl=> select '4 hours'::timespan;
----------------------------
@ 3 hours 59 mins 60.00 secs
(1 row)
Oliver was working on patches. Lost his e-mail message; is Oliver still
here? I've got a RH5.0 linux system at work now, and the shipped Postgres
installation has this problem. I'd like to see it fixed...
Bruce, can you add this to the v6.3 ToDo (assuming you agree to take it
on :)
- Tom
On Fri, 13 Feb 1998, Thomas G. Lockhart wrote:
> _ freebsd,etc (marc) (I don't know the different bsd variants)
FreeBSD is confirmed recently, but will be doing a new build this
weekend now that all the subselect code is in place...I also have access
to a Net/BSD machine that I'll be connecting to over the weekend and doing
a build/test on there also...
> _ ix86/solaris(marc) - confirmed working
> _ sparc/solaris(marc) - confirmed working
> _ sparc/sunos
- I have an old SunOS machine here at work that I can most likely
run it on, if nobody else wishes to volunteer...I don't know if it even
has a compiler on it, its only used as a console server in our machine
room :)
> > Bruce, are you planning on keeping a ToDo list for the 6.3 release as > you have in (at least) the past few releases? That will make sure that > we don't leave something out. As a start: Yea, I have stuff in my mailbox. Now that subselects are done, I can start putting together a list. This helps me get started. > > Commit sgml document sources(Thomas) > Commit html documents(Thomas) > Commit postscript documents(Thomas) > Fix aggregates in views reported by Brett > Include subselect regression tests(Thomas, unless someone else wants it > :) > Fix crashes from backend collisions reported by Tom H. > Fix isinf.c irix port problem reported by Andrew(Marc) > Check triggers regression test(Vadim) > Check select_views regression test > Test ecpg new struct features(Michael) > Test big-endian/little-endian operation(Tatsuo?) I don' know if we need > this... > > Confirm ports for v6.3 (need this soon for docs): > > _ aix4.2 - already fixed? what are actual versions?? > _ aix3.5 > _ bsdi > _ freebsd,etc (I don't know the different bsd variants) > _ 68k/bsdXXX (Macintosh port) never successful? Needed 68k locking > code?? > _ dgux > _ hpux9.0.x > _ hpux10.20 > _ alpha/unix - currently broken? > _ alpha/linux - currently broken? > _ ppc/mklinux(Tatsuo?) > * ix86/linux(Thomas) - confirmed working > _ ix86/solaris > _ irix5 > _ irix6 > _ nextstep - not tested? not working?? > _ sco > _ sparc/solaris > _ sparc/sunos > _ svr4(which platforms?) > _ ultrix4 > _ univel > > If a platform does not get on this list, and have a confirmed > compile/regression test, then it will go on the unsupported list for > v6.3 :( The regression tests do not have to pass completely (since > there are a couple of remaining beta problems) but the port should > compile, run, and produce reasonable results for most tests. > > Can people commit to checking on each platform? (I know some have been > done already...) > > -- Bruce Momjian maillist@candle.pha.pa.us
> Oliver was working on patches. Lost his e-mail message; is Oliver still > here? I've got a RH5.0 linux system at work now, and the shipped Postgres > installation has this problem. I'd like to see it fixed... > > Bruce, can you add this to the v6.3 ToDo (assuming you agree to take it > on :) To be honest, I there has been so much going on, I am not sure what to document, especially with the ports. I don't think I ever did a good job of tracking which ports did and did not work. I usually concentrated on show-stopper bugs like crashes and broken features. -- Bruce Momjian maillist@candle.pha.pa.us
> Oliver was working on patches. Lost his e-mail message; is Oliver still > here? I've got a RH5.0 linux system at work now, and the shipped Postgres > installation has this problem. I'd like to see it fixed... > > Bruce, can you add this to the v6.3 ToDo (assuming you agree to take it > on :) Marc and Thomas, there are so many patches going around, I can't even keep track that they are all getting applied. Thank goodness Marc is on top of it. -- Bruce Momjian maillist@candle.pha.pa.us
On Fri, 13 Feb 1998, Bruce Momjian wrote:
> > Oliver was working on patches. Lost his e-mail message; is Oliver still
> > here? I've got a RH5.0 linux system at work now, and the shipped Postgres
> > installation has this problem. I'd like to see it fixed...
> >
> > Bruce, can you add this to the v6.3 ToDo (assuming you agree to take it
> > on :)
>
> Marc and Thomas, there are so many patches going around, I can't even
> keep track that they are all getting applied. Thank goodness Marc is on
> top of it.
I'm trying...there are some that I let "slip" I'm uncertain of
them. If *anyone* has submitted a patch recently that hasn't been
applied, it may have slipped through the cracks inadvertantly...please
repost it with a subject that includes "*REPOST*" in it...
Bruce/Thomas/Vadim...if you see one of those go through, please
take a scan as it, cause there is a good chance that I didn't apply it due
to uncertainty...
> > On Fri, 13 Feb 1998, Bruce Momjian wrote: > > > > Oliver was working on patches. Lost his e-mail message; is Oliver still > > > here? I've got a RH5.0 linux system at work now, and the shipped Postgres > > > installation has this problem. I'd like to see it fixed... > > > > > > Bruce, can you add this to the v6.3 ToDo (assuming you agree to take it > > > on :) > > > > Marc and Thomas, there are so many patches going around, I can't even > > keep track that they are all getting applied. Thank goodness Marc is on > > top of it. > > I'm trying...there are some that I let "slip" I'm uncertain of > them. If *anyone* has submitted a patch recently that hasn't been > applied, it may have slipped through the cracks inadvertantly...please > repost it with a subject that includes "*REPOST*" in it... > > Bruce/Thomas/Vadim...if you see one of those go through, please > take a scan as it, cause there is a good chance that I didn't apply it due > to uncertainty... Problem is, I have never been able to determine what patches you are uncertain about. -- Bruce Momjian maillist@candle.pha.pa.us
On Fri, 13 Feb 1998, Bruce Momjian wrote:
> Problem is, I have never been able to determine what patches you are
> uncertain about.
Okay, I'll start replying to the list about patches that I'm not
personally comfortable with applying...most look okay, and I'll apply
them, but some of htem...
At 8:08 AM -0800 2/13/98, Thomas G. Lockhart wrote: >Bruce, are you planning on keeping a ToDo list for the 6.3 release as >_ 68k/bsdXXX (Macintosh port) never successful? Needed 68k locking >code?? That's NetBSD/m68k properly speaking since the difference between an Amiga, an HP 300 and a Macintosh is only visible inside the kernel. Userland binaries are identical for all 68000 NetBSD ports. Most likely my problems would also exist for OpenBSD/m68k. I wrote the 68k locking code and fixed the include file so it would recognize that the code only existed for certain specific CPU's, not for all NetBSD ports. This was not strictly necessary to get it to work; just what I *could* do. As of 6.2.x Postgres does not work with NetBSD/m68k. I have not had time to test with 6.3beta. It dies during initdb, just like the linux/alpha version. Tom Helbekkmo reports that Postgres works just fine on NetBSD/sparc (though you should check he's tried a recient version there), and I feel fairly confident of NetBSD/i386 in view of the FreeBSD contengent. Signature failed Preliminary Design Review. Feasibility of a new signature is currently being evaluated. h.b.hotz@jpl.nasa.gov, or hbhotz@oxy.edu
> > On Fri, 13 Feb 1998, Bruce Momjian wrote: > > > Problem is, I have never been able to determine what patches you are > > uncertain about. > > Okay, I'll start replying to the list about patches that I'm not > personally comfortable with applying...most look okay, and I'll apply > them, but some of htem... Usually we pipe up when we see a bad patch, but not always. -- Bruce Momjian maillist@candle.pha.pa.us
Here are the items. --------------------------------------------------------------------------- ORDER BY NULLs problem? pg_user not world-readable, no initdb password option(Todd Brandys) make psql \d optionally user pg_user(Bruce) optimizer memory exhaustion with many OR's max tuple size patch(Darren) Is GROUP BY duplicates fixed? Do we have a self-join optimizer performance problem? Get interfaces fixed for new protocol Profiling improvements? Do we have a problem with GROUP BY without ORDER BY? Problem with tables >2Gb Do we want to add timestamps to elog messages? ScanKeyData missing initializations Can we improve vacuum locking issues? Alpha/64-bit issues, mkoidname() problem 'Can not write block blind' error on createdb and regression collision Views on aggregates fail large objects memory exhaustion subselect issues, NOT IN (empty query) Commit sgml document sources(Thomas) Commit html documents(Thomas) Commit postscript documents(Thomas) Include subselect regression tests Fix isinf.c irix port problem reported by Andrew(Marc) Check triggers regression test(Vadim) Check select_views regression test Test ecpg new struct features(Michael) Test big-endian/little-endian operation(Tatsuo?)? Linux library issues? -- Bruce Momjian maillist@candle.pha.pa.us
On Fri, 13 Feb 1998, Bruce Momjian wrote:
> >
> > On Fri, 13 Feb 1998, Bruce Momjian wrote:
> >
> > > Problem is, I have never been able to determine what patches you are
> > > uncertain about.
> >
> > Okay, I'll start replying to the list about patches that I'm not
> > personally comfortable with applying...most look okay, and I'll apply
> > them, but some of htem...
>
> Usually we pipe up when we see a bad patch, but not always.
Hrmmm, so reasonably safe to just apply a patch and expect that if
its a problem, someone will yell at me about it? :)
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
On Fri, Feb 13, 1998 at 12:31:32PM -0800, Henry B. Hotz wrote: > Tom Helbekkmo reports that Postgres works just fine on NetBSD/sparc > (though you should check he's tried a recient version there), and I > feel fairly confident of NetBSD/i386 in view of the FreeBSD contengent. I rebuild everything under NetBSD/sparc and NetBSD/vax at least twice per week, and will try to increase the rebuild rate as the release draws near. If I can just get around to replacing the power supply in my old i386 box, I can do the same for NetBSD/i386. However: reading regression test output is a royal pain. We're talking almost 100 kilobytes of 'diff' output per platform, most of which is last digit differences in floating point numbers and slightly different wording of (expected) error messages. I cannot guarantee that I don't miss actual problems in there that mean something relevant. So far things look pretty good, though. -tih -- Popularity is the hallmark of mediocrity. --Niles Crane, "Frasier"
Re: [HACKERS] Re: [PORTS] v6.3 release ToDo list and supported ports
From
"Thomas G. Lockhart"
Date:
> > Tom Helbekkmo reports that Postgres works just fine on NetBSD/sparc
> > (though you should check he's tried a recient version there), and I
> > feel fairly confident of NetBSD/i386 in view of the FreeBSD contengent.
>
> I rebuild everything under NetBSD/sparc and NetBSD/vax at least twice
> per week, and will try to increase the rebuild rate as the release
> draws near. If I can just get around to replacing the power supply in
> my old i386 box, I can do the same for NetBSD/i386.
>
> However: reading regression test output is a royal pain. We're
> talking almost 100 kilobytes of 'diff' output per platform, most of
> which is last digit differences in floating point numbers and slightly
> different wording of (expected) error messages. I cannot guarantee
> that I don't miss actual problems in there that mean something
> relevant. So far things look pretty good, though.
That counts as a working port for v6.3, since there are not likely to be
changes that break individual ports from here on. If there is a change which
might, then we will post a "call for port testing" on hackers. No need to do
explicit port testing on a daily/weekly basis once a port has been shown to
work in the last few weeks, although it would be a good idea to do it once
more perhaps a few days before the release.
I'll take on the list of tested ports if someone has not already, since I'll
want to fold it into the docs anyway. Will repost my current list soon.
- Tom
> > On Fri, 13 Feb 1998, Bruce Momjian wrote: > > > > > > > On Fri, 13 Feb 1998, Bruce Momjian wrote: > > > > > > > Problem is, I have never been able to determine what patches you are > > > > uncertain about. > > > > > > Okay, I'll start replying to the list about patches that I'm not > > > personally comfortable with applying...most look okay, and I'll apply > > > them, but some of htem... > > > > Usually we pipe up when we see a bad patch, but not always. > > Hrmmm, so reasonably safe to just apply a patch and expect that if > its a problem, someone will yell at me about it? :) Yep. -- Bruce Momjian maillist@candle.pha.pa.us
Thomas G. Lockhart wrote: > > Include subselect regression tests(Thomas, unless someone else wants it :) Oh, thanks! Vadim
> > Thomas G. Lockhart wrote: > > > > Include subselect regression tests(Thomas, unless someone else wants it :) > > Oh, thanks! I think someone suggested using the MySQL crashme test for subselects. MySQL doesn't have subselects. -- Bruce Momjian maillist@candle.pha.pa.us
Bruce Momjian wrote:
>
> >
> > Thomas G. Lockhart wrote:
> > >
> > > Include subselect regression tests(Thomas, unless someone else wants it :)
> >
> > Oh, thanks!
>
> I think someone suggested using the MySQL crashme test for subselects.
> MySQL doesn't have subselects.
^^^^^^^^^^^^^
Me. I know, but I thought that crashme tests more features than
MySQL has itself.
Vadim
> > Bruce Momjian wrote: > > > > > > > > Thomas G. Lockhart wrote: > > > > > > > > Include subselect regression tests(Thomas, unless someone else wants it :) > > > > > > Oh, thanks! > > > > I think someone suggested using the MySQL crashme test for subselects. > > MySQL doesn't have subselects. > ^^^^^^^^^^^^^ > Me. I know, but I thought that crashme tests more features than > MySQL has itself. Good question. I don't know the answer myself. -- Bruce Momjian maillist@candle.pha.pa.us