Thread: Call for platforms
OK, here is my current platform list taken from the -hackers list and
from Vince's web page. I'm sure I've missed at least a few reports, but
please confirm that platforms are actually running and passing
regression tests with recent betas or the latest release candidate.
If a platform you are running on is not listed, make sure it gets
included! Platforms with reports for 7.0 risk being demoted to the "used
to be supported list", and platforms with reports for only 6.5 are on a
deathwatch, so be sure to speak up! Also, I've included names below to
remind us who helped last time, but feel free to report even if your
name is not already listed.
I've separated out recent reports and put them at the end of the list.
Thanks in advance.
- Thomas
AIX 4.3.2 RS6000 7.0 2000-04-05, Andreas Zeugswetter
Compaq Tru64 5.0 Alpha 7.0 2000-04-11, Andrew McMurry
IRIX 6.5.6f MIPS 6.5.3 2000-02-18, Kevin Wheatley
Linux 2.2.x armv4l 7.0 2000-04-17, Mark Knox
Linux 2.0.x MIPS 7.0 2000-04-13, Tatsuo Ishii
mklinux PPC750 7.0 2000-04-13, Tatsuo Ishii
NetBSD 1.4 arm32 7.0 2000-04-08, Patrick Welche
NetBSD 1.4U x86 7.0 2000-03-26, Patrick Welche
NetBSD m68k 7.0 2000-04-10, Henry B. Hotz
NetBSD Sparc 7.0 2000-04-13, Tom I. Helbekkmo
QNX 4.25 x86 7.0 2000-04-01, Dr. Andreas Kardos
SCO OpenServer 5 x86 6.5 1999-05-25, Andrew Merrill
Solaris x86 7.0 2000-04-12, Marc Fournier
Solaris 2.5.1-2.7 Sparc 7.0 2000-04-12, Peter Eisentraut
SunOS 4.1.4 Sparc 7.0 2000-04-13, Tatsuo Ishii
Windows/Win32 x86 7.0 2000-04-02, Magnus Hagander (clients only)
WinNT/Cygwin x86 7.0 2000-03-30, Daniel Horak
BeOS 5.0.3 x86 7.1 2000-12-18, Cyril Velter
BSDI 4.01 x86 7.1 2001-03-19, Bruce Momjian
FreeBSD 4.2 x86 7.1 2001-03-19, Vince Vielhaber
HPUX 10.20 PA-RISC 7.1 2001-03-19, Tom Lane
IBM S/390 7.1 2000-11-17, Neale Ferguson
Linux 2.2.x Alpha 7.1 2001-01-23, Ryan Kirkpatrick
Linux 2.2.16 x86 7.1 2001-03-19, Thomas Lockhart
Linux 2.2.15 Sparc 7.1 2001-01-30, Ryan Kirkpatrick
LinuxPPC G3 7.1 2001-03-19, Tom Lane
SCO UnixWare 7.1.1 x86 7.1 2001-03-19, Larry Rosenman
MacOS-X Darwin PowerPC 7.1 2000-12-11, Peter Bierman
* Thomas Lockhart <lockhart@alumni.caltech.edu> [010320 20:04]: > OK, here is my current platform list taken from the -hackers list and > from Vince's web page. I'm sure I've missed at least a few reports, but > please confirm that platforms are actually running and passing > regression tests with recent betas or the latest release candidate. > > If a platform you are running on is not listed, make sure it gets > included! Platforms with reports for 7.0 risk being demoted to the "used > to be supported list", and platforms with reports for only 6.5 are on a > deathwatch, so be sure to speak up! Also, I've included names below to > remind us who helped last time, but feel free to report even if your > name is not already listed. FreeBSD 4.3-BETA (will be -RELEASE by the time we release) works too. I reported FreeBSD 4.[23]. LER > > I've separated out recent reports and put them at the end of the list. > Thanks in advance. > > - Thomas > > AIX 4.3.2 RS6000 7.0 2000-04-05, Andreas Zeugswetter > Compaq Tru64 5.0 Alpha 7.0 2000-04-11, Andrew McMurry > IRIX 6.5.6f MIPS 6.5.3 2000-02-18, Kevin Wheatley > Linux 2.2.x armv4l 7.0 2000-04-17, Mark Knox > Linux 2.0.x MIPS 7.0 2000-04-13, Tatsuo Ishii > mklinux PPC750 7.0 2000-04-13, Tatsuo Ishii > NetBSD 1.4 arm32 7.0 2000-04-08, Patrick Welche > NetBSD 1.4U x86 7.0 2000-03-26, Patrick Welche > NetBSD m68k 7.0 2000-04-10, Henry B. Hotz > NetBSD Sparc 7.0 2000-04-13, Tom I. Helbekkmo > QNX 4.25 x86 7.0 2000-04-01, Dr. Andreas Kardos > SCO OpenServer 5 x86 6.5 1999-05-25, Andrew Merrill > Solaris x86 7.0 2000-04-12, Marc Fournier > Solaris 2.5.1-2.7 Sparc 7.0 2000-04-12, Peter Eisentraut > SunOS 4.1.4 Sparc 7.0 2000-04-13, Tatsuo Ishii > Windows/Win32 x86 7.0 2000-04-02, Magnus Hagander (clients only) > WinNT/Cygwin x86 7.0 2000-03-30, Daniel Horak > > BeOS 5.0.3 x86 7.1 2000-12-18, Cyril Velter > BSDI 4.01 x86 7.1 2001-03-19, Bruce Momjian > FreeBSD 4.2 x86 7.1 2001-03-19, Vince Vielhaber > HPUX 10.20 PA-RISC 7.1 2001-03-19, Tom Lane > IBM S/390 7.1 2000-11-17, Neale Ferguson > Linux 2.2.x Alpha 7.1 2001-01-23, Ryan Kirkpatrick > Linux 2.2.16 x86 7.1 2001-03-19, Thomas Lockhart > Linux 2.2.15 Sparc 7.1 2001-01-30, Ryan Kirkpatrick > LinuxPPC G3 7.1 2001-03-19, Tom Lane > SCO UnixWare 7.1.1 x86 7.1 2001-03-19, Larry Rosenman > MacOS-X Darwin PowerPC 7.1 2000-12-11, Peter Bierman > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/users-lounge/docs/faq.html -- 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
> SCO OpenServer 5 x86...
OK, I see that Billy Allie recently updated FAQ_SCO to indicate
demonstrated (?) support for OpenServer. I will reflect that in the
platform support info.
- Thomas
> mklinux PPC750 7.0 2000-04-13, Tatsuo Ishii I got core dump while running the parallel regression test of beta6. Will look at... -- Tatsuo Ishii
> Compaq Tru64 5.0 Alpha 7.0 2000-04-11, Andrew McMurry We've got 7.0.3 and 7.1b4 running on Compaq Tru64 4.0G Alpha Will do the regression test once RC1 is out. Adriaan
> > mklinux PPC750 7.0 2000-04-13, Tatsuo Ishii > > I got core dump while running the parallel regression test of beta6. > Will look at... > -- > Tatsuo Ishii VACUUM; ! FATAL 2: ZeroFill(logfile 0 seg 1) failed: No such file or directory ! pqReadData() -- backend closed the channel unexpectedly. maybe a bug related to Tom recently fixed? If so, I will try RC1... -- Tatsuo Ishii
Tatsuo Ishii <t-ishii@sra.co.jp> writes:
> ! FATAL 2: ZeroFill(logfile 0 seg 1) failed: No such file or directory
> ! pqReadData() -- backend closed the channel unexpectedly.
Is it possible you ran out of disk space?
regards, tom lane
> Tatsuo Ishii <t-ishii@sra.co.jp> writes: > > ! FATAL 2: ZeroFill(logfile 0 seg 1) failed: No such file or directory > > ! pqReadData() -- backend closed the channel unexpectedly. > > Is it possible you ran out of disk space? Probably not. -- Tatsuo Ishii
Thomas Lockhart writes: > > SCO OpenServer 5 x86... > > OK, I see that Billy Allie recently updated FAQ_SCO to indicate > demonstrated (?) support for OpenServer. I will reflect that in the > platform support info. The last FAQ_SCO update was by me, and it was rather the consequence of some implementational developments and not a good indicator of any actually working platform. (I do have access to a Unixware box, but that was already reported.) -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
Hi, I reported Linux RedHat 6.2 - 2.2.14-5.0smp #1 SMP Tue Mar 7 21:01:40 EST 2000 i686 2 cpu - 1Go RAM Gilles DAROLD
Hi, I am currently testing beta6 on AIX 4.3.3 on a RS6000 H80 with 4 cpu and 4 Go RAM I use : ./configure --with-CC=/usr/local/bin/gcc --with-includes=/usr/local/include --with-libraries=/usr/local/lib All seem to be ok, There just the geometry failure in regression test (following the AIX FAQ it's normal ?) But when I configure with --with-perl I have the following error : make[4]: cc : Command not found Any idea ? Gilles DAROLD > Hi, > > I reported Linux RedHat 6.2 - 2.2.14-5.0smp #1 SMP Tue Mar 7 21:01:40 EST > 2000 i686 > 2 cpu - 1Go RAM > > Gilles DAROLD > > ---------------------------(end of broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://www.postgresql.org/search.mpl
I see nobody did a test of 7.1 on Linux 2.4.x ? Would be nice to certify it is running on kernel 2.4.x as they claim this is entreprise strength kernel... Cheers. Thomas Lockhart wrote: > > > AIX 4.3.2 RS6000 7.0 2000-04-05, Andreas Zeugswetter > Compaq Tru64 5.0 Alpha 7.0 2000-04-11, Andrew McMurry > IRIX 6.5.6f MIPS 6.5.3 2000-02-18, Kevin Wheatley > Linux 2.2.x armv4l 7.0 2000-04-17, Mark Knox > Linux 2.0.x MIPS 7.0 2000-04-13, Tatsuo Ishii > mklinux PPC750 7.0 2000-04-13, Tatsuo Ishii > NetBSD 1.4 arm32 7.0 2000-04-08, Patrick Welche > NetBSD 1.4U x86 7.0 2000-03-26, Patrick Welche > NetBSD m68k 7.0 2000-04-10, Henry B. Hotz > NetBSD Sparc 7.0 2000-04-13, Tom I. Helbekkmo > QNX 4.25 x86 7.0 2000-04-01, Dr. Andreas Kardos > SCO OpenServer 5 x86 6.5 1999-05-25, Andrew Merrill > Solaris x86 7.0 2000-04-12, Marc Fournier > Solaris 2.5.1-2.7 Sparc 7.0 2000-04-12, Peter Eisentraut > SunOS 4.1.4 Sparc 7.0 2000-04-13, Tatsuo Ishii > Windows/Win32 x86 7.0 2000-04-02, Magnus Hagander (clients only) > WinNT/Cygwin x86 7.0 2000-03-30, Daniel Horak > > BeOS 5.0.3 x86 7.1 2000-12-18, Cyril Velter > BSDI 4.01 x86 7.1 2001-03-19, Bruce Momjian > FreeBSD 4.2 x86 7.1 2001-03-19, Vince Vielhaber > HPUX 10.20 PA-RISC 7.1 2001-03-19, Tom Lane > IBM S/390 7.1 2000-11-17, Neale Ferguson > Linux 2.2.x Alpha 7.1 2001-01-23, Ryan Kirkpatrick > Linux 2.2.16 x86 7.1 2001-03-19, Thomas Lockhart > Linux 2.2.15 Sparc 7.1 2001-01-30, Ryan Kirkpatrick > LinuxPPC G3 7.1 2001-03-19, Tom Lane > SCO UnixWare 7.1.1 x86 7.1 2001-03-19, Larry Rosenman > MacOS-X Darwin PowerPC 7.1 2000-12-11, Peter Bierman > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/users-lounge/docs/faq.html
Franck Martin <franck@sopac.org> writes: > Would be nice to certify it is running on kernel 2.4.x as they claim this > is entreprise strength kernel... Lamar, if you send me your SRPM I can do that... -- Trond Eivind Glomsrød Red Hat, Inc.
Tatsuo Ishii <t-ishii@sra.co.jp> writes:
>> Tatsuo Ishii <t-ishii@sra.co.jp> writes:
> ! FATAL 2: ZeroFill(logfile 0 seg 1) failed: No such file or directory
> ! pqReadData() -- backend closed the channel unexpectedly.
>>
>> Is it possible you ran out of disk space?
> Probably not.
The reason I was speculating that was that it seems pretty unlikely
that a write() call could return ENOENT, as the above appears to
suggest. I think that the errno = ENOENT value was not set by write(),
but is leftover from the expected failure of BasicOpenFile earlier in
XLogFileInit. Probably write() returned some value less than BLCKSZ
but more than zero, and so did not set errno.
Offhand the only reason I can think of for a write to a disk file
to terminate after a partial transfer is a full disk. What do you
think?
regards, tom lane
* Tom Lane <tgl@sss.pgh.pa.us> [010321 21:29]: > Tatsuo Ishii <t-ishii@sra.co.jp> writes: > >> Tatsuo Ishii <t-ishii@sra.co.jp> writes: > > ! FATAL 2: ZeroFill(logfile 0 seg 1) failed: No such file or directory > > ! pqReadData() -- backend closed the channel unexpectedly. > >> > >> Is it possible you ran out of disk space? > > > Probably not. > > The reason I was speculating that was that it seems pretty unlikely > that a write() call could return ENOENT, as the above appears to > suggest. I think that the errno = ENOENT value was not set by write(), > but is leftover from the expected failure of BasicOpenFile earlier in > XLogFileInit. Probably write() returned some value less than BLCKSZ > but more than zero, and so did not set errno. > > Offhand the only reason I can think of for a write to a disk file > to terminate after a partial transfer is a full disk. What do you > think? What about hitting a quota? LER > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go 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
On Thu, Mar 22, 2001 at 12:31:03PM +1200, Franck Martin wrote: > I see nobody did a test of 7.1 on Linux 2.4.x ? > > Would be nice to certify it is running on kernel 2.4.x as they claim this > is entreprise strength kernel... I've been running the 7.1 betas on 2.4 for weeks without any problems. I replied to the "call for platforms" e-mail, but it looks like it got lost in the avalanche.I'll run the regression tests with the latest CVS snapshot and submit a report to the list. -Roberto -- +----| http://fslc.usu.edu USU Free Software & GNU/Linux Club|------+ Roberto Mello - Computer Science, USU - http://www.brasileiro.net http://www.sdl.usu.edu - Space Dynamics Lab, Web Developer
OK: Linux 2.4.2 i686 / gcc 2.95.2 / Debian testing/unstable no problems. OK?: NetBSD 1.5 i586 / egcs 2.91.66 / (netbsd-1-5 from Jan) netbsd FAILED the geometry test, diff attached, dunno if its critical or not. -- marko
Attachment
Here is the current scorecard. We have a couple of new platforms reported (yeaaa!): NetBSD 2.8 alpha 7.1 2001-03-22, Giles Lean OpenBSD 2.8 x86 7.1 2001-03-22, B. Palmer (first name?) Any more OpenBSD architectures out there running PostgreSQL? Here are the remaining (unreported, or unnoted) platforms: IRIX 6.5.6f MIPS 6.5.3 2000-02-18, Kevin Wheatley Anyone running IRIX? It may be on the unsupported list for 7.1 :( Linux 2.2.x armv4l 7.0 2000-04-17, Mark Knox Linux 2.0.x MIPS 7.0 2000-04-13, Tatsuo Ishii mklinux PPC750 7.0 2000-04-13, Tatsuo Ishii Tatsuo, do you still have access to the MIPS box? NetBSD m68k 7.0 2000-04-10, Henry B. Hotz NetBSD Sparc 7.0 2000-04-13, Tom I. Helbekkmo QNX 4.25 x86 7.0 2000-04-01, Dr. Andreas Kardos cvs shows that there were patches from Maurizio in February, and he said that ecpg worked for him. Bruce applied the patches, but I'm not certain that this was done on the 7.1 code tree? Bruce, do you recall anything? Solaris x86 7.0 2000-04-12, Marc Fournier scrappy, do you still have this machine? Solaris 2.5.1-2.7 Sparc 7.0 2000-04-12, Peter Eisentraut I'll bet that someone already has Solaris covered. Report? SunOS 4.1.4 Sparc 7.0 2000-04-13, Tatsuo Ishii Tatsuo, I vaguely recall that you reported trouble recently. Is this worth continuing as a supported platform? Windows/Win32 x86 7.0 2000-04-02, Magnus Hagander (clients only) Anyone compiled for Win32 recently? And here are the up-to-date platforms; thanks for the reports: AIX 4.3.3 RS6000 7.1 2001-03-21, Gilles Darold BeOS 5.0.3 x86 7.1 2000-12-18, Cyril Velter BSDI 4.01 x86 7.1 2001-03-19, Bruce Momjian Compaq Tru64 5.0 Alpha 7.0 2000-04-11, Andrew McMurry FreeBSD 4.2 x86 7.1 2001-03-19, Vince Vielhaber HPUX 10.20 PA-RISC 7.1 2001-03-19, Tom Lane IBM S/390 7.1 2000-11-17, Neale Ferguson Linux 2.2.x Alpha 7.1 2001-01-23, Ryan Kirkpatrick Linux 2.2.16 x86 7.1 2001-03-19, Thomas Lockhart Linux 2.2.15 Sparc 7.1 2001-01-30, Ryan Kirkpatrick LinuxPPC G3 7.1 2001-03-19, Tom Lane NetBSD 1.5E arm32 7.1 2001-03-21, Patrick Welche NetBSD 1.5S x86 7.1 2001-03-21, Patrick Welche SCO OpenServer 5 x86 7.1 2001-03-13, Billy Allie SCO UnixWare 7.1.1 x86 7.1 2001-03-19, Larry Rosenman MacOS-X Darwin PowerPC 7.1 2000-12-11, Peter Bierman WinNT/Cygwin x86 7.1 2001-03-16, Jason Tishler
On Thu, 22 Mar 2001, Thomas Lockhart wrote: > Solaris x86 7.0 2000-04-12, Marc Fournier > > scrappy, do you still have this machine? Doing tests on Solaris x86/7 right now, will report as soon as they are done ... > Solaris 2.5.1-2.7 Sparc 7.0 2000-04-12, Peter Eisentraut > > I'll bet that someone already has Solaris covered. Report? Will do up Sparc/7 also this morning ... > AIX 4.3.3 RS6000 7.1 2001-03-21, Gilles Darold > BeOS 5.0.3 x86 7.1 2000-12-18, Cyril Velter > BSDI 4.01 x86 7.1 2001-03-19, Bruce Momjian > Compaq Tru64 5.0 Alpha 7.0 2000-04-11, Andrew McMurry > FreeBSD 4.2 x86 7.1 2001-03-19, Vince Vielhaber FreeBSD 4.3-BETA is good to go also ...
> > FreeBSD 4.2 x86 7.1 2001-03-19, Vince Vielhaber
> FreeBSD 4.3-BETA is good to go also ...
Yeah, I'm not sure how to list that, or whether to bother. It is beta,
4.2 works fine (and nothing had to change for 4.3, right?) so maybe we
just list it when 4.3 goes stable? Or is 4.3 sufficiently different that
it would be good to list in the comments for the platform?
- Thomas
How much 'diviation' are we allowing for?
Solaris x86/7 results, for example, in geometry.out, show a difference of:
1.53102359078377e-11,3 (expected)
1.53102359017709e-11,3 (results)
or
3,-3.06204718156754e-11 (expected)
3,-3.06204718035418e-11 (results)
acceptable diviation?
On Thu, 22 Mar 2001, The Hermit Hacker wrote:
> On Thu, 22 Mar 2001, Thomas Lockhart wrote:
>
> > Solaris x86 7.0 2000-04-12, Marc Fournier
> >
> > scrappy, do you still have this machine?
>
> Doing tests on Solaris x86/7 right now, will report as soon as they are
> done ...
>
> > Solaris 2.5.1-2.7 Sparc 7.0 2000-04-12, Peter Eisentraut
> >
> > I'll bet that someone already has Solaris covered. Report?
>
> Will do up Sparc/7 also this morning ...
>
> > AIX 4.3.3 RS6000 7.1 2001-03-21, Gilles Darold
> > BeOS 5.0.3 x86 7.1 2000-12-18, Cyril Velter
> > BSDI 4.01 x86 7.1 2001-03-19, Bruce Momjian
> > Compaq Tru64 5.0 Alpha 7.0 2000-04-11, Andrew McMurry
> > FreeBSD 4.2 x86 7.1 2001-03-19, Vince Vielhaber
>
> FreeBSD 4.3-BETA is good to go also ...
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
>
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
> Solaris x86/7 results, for example, in geometry.out, show a difference of:
> 3,-3.06204718156754e-11 (expected)
> 3,-3.06204718035418e-11 (results)
> acceptable diviation?
That sort of deviation is well within bounds, particularly for geometry
tests which might have some transcendental math involved.
Is Solaris-x86 ready to go then?
- Thomas
4.3 is in RELEASE CANDIDATE right now. By the time we release, it should be -RELEASE or -STABLE. I'd include it as just 4.3. It will be the -RELEASE at the time we are. LER >>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<< On 3/22/01, 8:50:26 AM, Thomas Lockhart <lockhart@alumni.caltech.edu> wrote regarding [HACKERS] Re: Call for platforms: > > > FreeBSD 4.2 x86 7.1 2001-03-19, Vince Vielhaber > > FreeBSD 4.3-BETA is good to go also ... > Yeah, I'm not sure how to list that, or whether to bother. It is beta, > 4.2 works fine (and nothing had to change for 4.3, right?) so maybe we > just list it when 4.3 goes stable? Or is 4.3 sufficiently different that > it would be good to list in the comments for the platform? > - Thomas > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster
On Thu, 22 Mar 2001, Thomas Lockhart wrote: > > Solaris x86/7 results, for example, in geometry.out, show a difference of: > > 3,-3.06204718156754e-11 (expected) > > 3,-3.06204718035418e-11 (results) > > acceptable diviation? > > That sort of deviation is well within bounds, particularly for geometry > tests which might have some transcendental math involved. > > Is Solaris-x86 ready to go then? Nope, still working through some things ... the select_implicit test failed completely: dragon:/home/centre/marc/src/postgresql-7.1RC1/src/test/regress> more results/select_implicit.out psql: connectDBStart() -- connect() failed: Connection refused Is the postmaster running locally and acceptingconnections on Unix socket '/tmp/.s.PGSQL.65432'? I'm going to re-run the test(s) and see if its an isolated thing or not ...
The Hermit Hacker <scrappy@hub.org> writes:
> Nope, still working through some things ... the select_implicit test
> failed completely:
> dragon:/home/centre/marc/src/postgresql-7.1RC1/src/test/regress> more results/select_implicit.out
> psql: connectDBStart() -- connect() failed: Connection refused
> Is the postmaster running locally
> and accepting connections on Unix socket '/tmp/.s.PGSQL.65432'?
> I'm going to re-run the test(s) and see if its an isolated thing or not ...
Transient overflow of the postmaster socket's accept queue, maybe? How
big is SOMAXCONN on your box?
regards, tom lane
On Thu, 22 Mar 2001, Tom Lane wrote: > The Hermit Hacker <scrappy@hub.org> writes: > > Nope, still working through some things ... the select_implicit test > > failed completely: > > > dragon:/home/centre/marc/src/postgresql-7.1RC1/src/test/regress> more results/select_implicit.out > > psql: connectDBStart() -- connect() failed: Connection refused > > Is the postmaster running locally > > and accepting connections on Unix socket '/tmp/.s.PGSQL.65432'? > > > I'm going to re-run the test(s) and see if its an isolated thing or not ... > > Transient overflow of the postmaster socket's accept queue, maybe? How > big is SOMAXCONN on your box? Okay, for me, solaris has always been a nemesis as I can never find anything on this box :( But, looking through the header files, I find: /usr/include/sys/socket.h:#define SOMAXCONN 5 I reran the tests two more times since the above ... first time went through clean as could be, with the geometry test failing (forgot to update my expected/resultmaps file(s) in my compile tree), the second time failed *totally* different tests then the first run: dragon:/home/centre/marc/src/postgresql-7.1RC1/src/test/regress> grep FAILED regression.out opr_sanity ... FAILED join ... FAILED aggregates ... FAILED arrays ... FAILED I
The Hermit Hacker <scrappy@hub.org> writes:
> the second time
> failed *totally* different tests then the first run:
> dragon:/home/centre/marc/src/postgresql-7.1RC1/src/test/regress> grep
> FAILED regression.out
> opr_sanity ... FAILED
> join ... FAILED
> aggregates ... FAILED
> arrays ... FAILED
These are parallel tests right? What's the failure diffs?
regards, tom lane
The Hermit Hacker writes: > > Is Solaris-x86 ready to go then? > > Nope, still working through some things ... the select_implicit test > failed completely: > > dragon:/home/centre/marc/src/postgresql-7.1RC1/src/test/regress> more results/select_implicit.out > psql: connectDBStart() -- connect() failed: Connection refused > Is the postmaster running locally > and accepting connections on Unix socket '/tmp/.s.PGSQL.65432'? > > I'm going to re-run the test(s) and see if its an isolated thing or not ... Solaris is known to have trouble with Unix domain sockets. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
On Thu, 22 Mar 2001, Thomas Lockhart wrote: > OpenBSD 2.8 x86 7.1 2001-03-22, B. Palmer (first name?) Though it does work, like FBSD, there are some changes that need to be made to the system. Need max proc / files changes and a kernel recompile with SEMMNI and SEMMNS changes. Anywhere special to note this? b. palmer, bpalmer@crimelabs.net pgp: www.crimelabs.net/bpalmer.pgp5
The Hermit Hacker writes: > How much 'diviation' are we allowing for? > > Solaris x86/7 results, for example, in geometry.out, show a difference of: > > 1.53102359078377e-11,3 (expected) > 1.53102359017709e-11,3 (results) > > or > > 3,-3.06204718156754e-11 (expected) > 3,-3.06204718035418e-11 (results) > > acceptable diviation? Practically yes, technically not. Check if the geometry results match any of the other "expected" files so we can update the "resultmap". See http://www.postgresql.org/devel-corner/docs/postgres/regress-platform.html -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
Thomas Lockhart writes: > Here is the current scorecard. We have a couple of new platforms > reported (yeaaa!): > QNX 4.25 x86 7.0 2000-04-01, Dr. Andreas Kardos This one is getting a "no good", as of latest reports. There are some issues to be worked out in the dreaded spin lock area, which will probably not happen between now and next week. > And here are the up-to-date platforms; thanks for the reports: > IBM S/390 7.1 2000-11-17, Neale Ferguson ^^^should be "Linux" > LinuxPPC G3 7.1 2001-03-19, Tom Lane The kernel is called "Linux", the processor is called "PowerPC G3". But "PowerPC" is probably enough, given that we list "x86". Compare to... > MacOS-X Darwin PowerPC 7.1 2000-12-11, Peter Bierman ...this. There's a space, no dash, before the "X". -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
On Thu, Mar 22, 2001 at 05:25:01PM +0100, Peter Eisentraut wrote: > Marko Kreen writes: > > > > OK?: NetBSD 1.5 i586 / egcs 2.91.66 / (netbsd-1-5 from Jan) > > > > netbsd FAILED the geometry test, diff attached, dunno if its > > critical or not. > > Can you check whether it matches any of the other possible geometry > results? See Yes, it matches geometry-positive-zeros-bsd.out. There is another report about NetBSD 1.5/i386 which has comment: > one spurious floating point test failure > (mail sent to postgresql-bugs with details) But I could not find it in archive page. (reporter Giles Lean <giles@nemeton.com.au>) Perhaps same thing? -- marko
On Thu, 22 Mar 2001, Tom Lane wrote: > The Hermit Hacker <scrappy@hub.org> writes: > > the second time > > failed *totally* different tests then the first run: > > > dragon:/home/centre/marc/src/postgresql-7.1RC1/src/test/regress> grep > > FAILED regression.out > > opr_sanity ... FAILED > > join ... FAILED > > aggregates ... FAILED > > arrays ... FAILED > > These are parallel tests right? What's the failure diffs? same as last time: dragon:/home/centre/marc/src/postgresql-7.1RC1/src/test/regress> more results/opr_sanity.out psql: connectDBStart() -- connect() failed: Connection refused Is the postmaster running locally and acceptingconnections on Unix socket '/tmp/.s.PGSQL.65432'? and yet another run (and different results): ============== shutting down postmaster ============== =================================================1 of 76 tests failed, 1 failed test(s) ignored. ================================================= The differences that caused some tests to fail can be viewed in the file `./regression.diffs'. A copy of the test summary that you see above is saved in the file `./regression.out'. make: *** [check] Error 1 dragon:/home/centre/marc/src/postgresql-7.1RC1/src/test/regress> grep FAILED regression.out test misc ... FAILED dragon:/home/centre/marc/src/postgresql-7.1RC1/src/test/regress>
The Hermit Hacker <scrappy@hub.org> writes:
>> These are parallel tests right? What's the failure diffs?
> same as last time:
> dragon:/home/centre/marc/src/postgresql-7.1RC1/src/test/regress> more
> results/opr_sanity.out
> psql: connectDBStart() -- connect() failed: Connection refused
> Is the postmaster running locally
> and accepting connections on Unix socket '/tmp/.s.PGSQL.65432'?
See Peter's comment elsewhere that he doesn't think Solaris handles
Unix socket connections very well. Try patching pg_regress to force
unix_sockets=no.
> and yet another run (and different results):
> =================================================
> 1 of 76 tests failed, 1 failed test(s) ignored.
> =================================================
That's just ye olde random "random" failure ...
regards, tom lane
Just a data point on the geometry test under NetBSD/i386 issue:
/etc/ld.so.conf by default now contains:
libm.so.0 machdep.fpu_present 1:libm387.so.0,libm.so.0
which means that if the sysctl machdep.fpu_present returns 1, load the
shared library libm387 to make use of the fpu.
If you remove /etc/ld.so.conf, so that ldd `which psql` does not show
-lm.0 => /usr/lib/libm387.so.0 -lm.0 => /usr/lib/libm.so.0
but only the libm.so.0 line
======================All 76 tests passed.
======================
If you replace the /etc/ld.so.conf file and have an fpu, then the geometry
test will fail with slightly different rounding.
Do we want a specific geometry-netbsd-i386-with-fpu.out where you must
also test
% sysctl machdep.fpu_present
machdep.fpu_present = 1
?
Cheers,
Patrick
PS: AFAIK geometry-positive-zeros-bsd works for all NetBSD platforms - the
above difference is only for i386 + fpu.
On Thu, Mar 22, 2001 at 07:12:39PM +0200, Marko Kreen wrote:
> On Thu, Mar 22, 2001 at 05:25:01PM +0100, Peter Eisentraut wrote:
> > Marko Kreen writes:
> > >
> > > OK?: NetBSD 1.5 i586 / egcs 2.91.66 / (netbsd-1-5 from Jan)
> > >
> > > netbsd FAILED the geometry test, diff attached, dunno if its
> > > critical or not.
> >
> > Can you check whether it matches any of the other possible geometry
> > results? See
>
> Yes, it matches geometry-positive-zeros-bsd.out. There is
> another report about NetBSD 1.5/i386 which has comment:
>
> > one spurious floating point test failure
> > (mail sent to postgresql-bugs with details)
>
> But I could not find it in archive page. (reporter Giles Lean
> <giles@nemeton.com.au>) Perhaps same thing?
>
> --
> marko
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
> PS: AFAIK geometry-positive-zeros-bsd works for all NetBSD platforms - the > above difference is only for i386 + fpu. It doesn't on NetBSD-1.5/alpha -- there geometry-positive-zeros is correct. Regards, Giles
On Thu, Mar 22, 2001 at 12:49:39PM -0500, Tom Lane wrote: > The Hermit Hacker <scrappy@hub.org> writes: > >> These are parallel tests right? What's the failure diffs? > > > same as last time: > > > dragon:/home/centre/marc/src/postgresql-7.1RC1/src/test/regress> more > > results/opr_sanity.out > > psql: connectDBStart() -- connect() failed: Connection refused > > Is the postmaster running locally > > and accepting connections on Unix socket '/tmp/.s.PGSQL.65432'? > > See Peter's comment elsewhere that he doesn't think Solaris handles > Unix socket connections very well. Try patching pg_regress to force > unix_sockets=no. > > > > and yet another run (and different results): > > > ================================================= > > 1 of 76 tests failed, 1 failed test(s) ignored. > > ================================================= > > That's just ye olde random "random" failure ... Funny, I get the more optimistic: ==================================================75 of 76 tests passed, 1 failed test(s) ignored. ================================================== Different version? PostgreSQL 7.1RC1
On Thu, Mar 22, 2001 at 10:27:44PM +0200, Marko Kreen wrote: > On Thu, Mar 22, 2001 at 07:58:04PM +0000, Patrick Welche wrote: > > > > AFAIK geometry-positive-zeros works for all NetBSD platforms - the > > above difference is only for i386 + fpu. > > Seems that following patch is needed. Now It Works For Me (tm). > Giles, does the regress test now succed for you? Your patch works for me (i386) - I'd just like to point out that it's because we are both running on peecees with fpus and thus with libm387 loaded (else works without patch) BTW NetBSD 2.8 alpha 7.1 2001-03-22, Giles Lean Shouldn't that be 1.5? Cheers, Patrick
> NetBSD 2.8 alpha 7.1 2001-03-22, Giles Lean Correction: NetBSD-1.5/alpha. Ciao, Giles
On Fri, Mar 23, 2001 at 06:25:50AM +1100, Giles Lean wrote: > > > PS: AFAIK geometry-positive-zeros-bsd works for all NetBSD platforms - the > > above difference is only for i386 + fpu. > > It doesn't on NetBSD-1.5/alpha -- there geometry-positive-zeros is > correct. Sorry, that should have read: AFAIK geometry-positive-zeros works for all NetBSD platforms - the above difference is only for i386 + fpu. (-bsd is for bsdi) Thanks for the correction, Patrick
Thomas Lockhart <lockhart@alumni.caltech.edu> writes: > If a platform you are running on is not listed, make sure it gets > included! Red Hat Linux, Wolverine Beta (and some updates) - glibc 2.2.2, 2.4.2ish kernel (read: lots of fixes), gcc 2.96RH: All 76 tests passed with 7.1beta6 (parallel_schedule). I'll update this info when we do our next release. -- Trond Eivind Glomsrød Red Hat, Inc.
teg@redhat.com (Trond Eivind Glomsrød) writes: > Thomas Lockhart <lockhart@alumni.caltech.edu> writes: > > > If a platform you are running on is not listed, make sure it gets > > included! > > Red Hat Linux, Wolverine Beta (and some updates) - glibc 2.2.2, > 2.4.2ish kernel (read: lots of fixes), gcc 2.96RH: All 76 tests passed > with 7.1beta6 (parallel_schedule). Forgot to mention: This is x86. -- Trond Eivind Glomsrød Red Hat, Inc.
On Thu, 22 Mar 2001, Patrick Welche wrote: > On Thu, Mar 22, 2001 at 12:49:39PM -0500, Tom Lane wrote: > > The Hermit Hacker <scrappy@hub.org> writes: > > >> These are parallel tests right? What's the failure diffs? > > > > > same as last time: > > > > > dragon:/home/centre/marc/src/postgresql-7.1RC1/src/test/regress> more > > > results/opr_sanity.out > > > psql: connectDBStart() -- connect() failed: Connection refused > > > Is the postmaster running locally > > > and accepting connections on Unix socket '/tmp/.s.PGSQL.65432'? > > > > See Peter's comment elsewhere that he doesn't think Solaris handles > > Unix socket connections very well. Try patching pg_regress to force > > unix_sockets=no. > > > > > > > and yet another run (and different results): > > > > > ================================================= > > > 1 of 76 tests failed, 1 failed test(s) ignored. > > > ================================================= > > > > That's just ye olde random "random" failure ... > > Funny, I get the more optimistic: > > ================================================== > 75 of 76 tests passed, 1 failed test(s) ignored. > ================================================== > > Different version? PostgreSQL 7.1RC1 7.1RC1 (the not released yet version) :)
On 22 Mar 2001, Trond Eivind [iso-8859-1] Glomsr�d wrote: > teg@redhat.com (Trond Eivind Glomsr�d) writes: > > > Thomas Lockhart <lockhart@alumni.caltech.edu> writes: > > > > > If a platform you are running on is not listed, make sure it gets > > > included! > > > > Red Hat Linux, Wolverine Beta (and some updates) - glibc 2.2.2, > > 2.4.2ish kernel (read: lots of fixes), gcc 2.96RH: All 76 tests passed > > with 7.1beta6 (parallel_schedule). > > Forgot to mention: This is x86. Forget to enter it into the regresstest database? http://www.postgresql.org/~vev/regress/ 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 ==========================================================================
I have tested today's snap shot on SunOS4. % uname -a SunOS srashd 4.1.4-JL 1 sun4m There's a minor portability problem in src/bin/pg_encoding/Makefile. *** Makefile Fri Mar 23 11:53:49 2001 --- Makefile.orig Wed Feb 21 18:05:21 2001 *************** *** 16,28 **** all: submake pg_encoding - ifdef STRTOUL - OBJS+=$(top_builddir)/src/backend/port/strtoul.o - - $(top_builddir)/src/backend/port/strtoul.o: - $(MAKE) -C $(top_builddir)/src/backend/port strtoul.o - endif - pg_encoding: $(OBJS) $(CC) $(CFLAGS) $^ $(libpq) $(LDFLAGS) $(LIBS) -o $@ I'm going to check in this correction soon. For the regression test, I got 7 failures, most of them seem harmless, the only concern I have is bit test though. -- Tatsuo Ishii P.S. I'm going to test Linux/MIPS (Cobalt RaQ2) soon... -- Tatsuo Ishii
Tatsuo Ishii <t-ishii@sra.co.jp> writes:
> For the regression test, I got 7 failures, most of them seem harmless,
> the only concern I have is bit test though.
Most of the diffs derive from what I recall to be a known SunOS problem,
that strtol fails to notice overflow. A value that should be rejected
is getting inserted into int4_tbl (mod 2^32 of course).
The bit test diffs seem to indicate that bit_cmp is messed up. That
depends on memcmp. I seem to recall something about memcmp not being
8-bit-clean on SunOS ... does that ring a bell with anyone?
regards, tom lane
> I have tested today's snap shot on SunOS4.
> For the regression test, I got 7 failures, most of them seem harmless,
> the only concern I have is bit test though.
> P.S. I'm going to test Linux/MIPS (Cobalt RaQ2) soon...
Great! I'll update info for SunOS4 (individual problems will be fixed or
"known features" ;) and look forward to seeing the Linux/MIPS results.
- Thomas
> > I have tested today's snap shot on SunOS4. > > For the regression test, I got 7 failures, most of them seem harmless, > > the only concern I have is bit test though. > > P.S. I'm going to test Linux/MIPS (Cobalt RaQ2) soon... > > Great! I'll update info for SunOS4 (individual problems will be fixed or > "known features" ;) and look forward to seeing the Linux/MIPS results. Sorry, after moving of my office, this is the first time to boot RaQ2 but it won't boot anymore. Seems there are some severe hardware troubles with it. Can anyone else do the testing instead of me? -- Tatsuo Ishii
> Tatsuo Ishii <t-ishii@sra.co.jp> writes:
> >> Tatsuo Ishii <t-ishii@sra.co.jp> writes:
> > ! FATAL 2: ZeroFill(logfile 0 seg 1) failed: No such file or directory
> > ! pqReadData() -- backend closed the channel unexpectedly.
> >>
> >> Is it possible you ran out of disk space?
>
> > Probably not.
>
> The reason I was speculating that was that it seems pretty unlikely
> that a write() call could return ENOENT, as the above appears to
> suggest. I think that the errno = ENOENT value was not set by write(),
> but is leftover from the expected failure of BasicOpenFile earlier in
> XLogFileInit. Probably write() returned some value less than BLCKSZ
> but more than zero, and so did not set errno.
>
> Offhand the only reason I can think of for a write to a disk file
> to terminate after a partial transfer is a full disk. What do you
> think?
Sorry, I was wrong. I accidentaly ran out the disk space.
BTW, I got segfault when I first try beta6 on this platform. To
investigae it, I recompiled with -g (without -O2) and now the problem
has gone. It sems there's something wrong with the compiler (gcc
version egcs-2.90.25 980302 (egcs-1.0.2 prerelease)) or potential bug
in 7.1, I don't know.
Anyway, the platform is too old now, and I would like to try it
another day with newer MkLinux version installed. I don't want to make
this as a show stopper for 7.1...
--
Tatsuo Ishii
*** ./expected/oid.out Tue Nov 21 12:23:20 2000
--- ./results/oid.out Thu Mar 22 15:58:56 2001
***************
*** 6,11 ****
--- 6,12 ---- INSERT INTO OID_TBL(f1) VALUES ('1235'); INSERT INTO OID_TBL(f1) VALUES ('987'); INSERT INTO OID_TBL(f1)
VALUES('-1040');
+ ERROR: oidin: error in "-1040": can't parse "-1040" INSERT INTO OID_TBL(f1) VALUES ('99999999'); INSERT INTO
OID_TBL(f1)VALUES (''); -- bad inputs
***************
*** 15,28 **** ERROR: oidin: error in "99asdfasd": can't parse "asdfasd" SELECT '' AS six, OID_TBL.*; six | f1
! -----+------------ | 1234 | 1235 | 987
- | 4294966256 | 99999999 | 0
! (6 rows) SELECT '' AS one, o.* FROM OID_TBL o WHERE o.f1 = 1234; one | f1
--- 16,28 ---- ERROR: oidin: error in "99asdfasd": can't parse "asdfasd" SELECT '' AS six, OID_TBL.*; six | f1
! -----+---------- | 1234 | 1235 | 987 | 99999999 | 0
! (5 rows) SELECT '' AS one, o.* FROM OID_TBL o WHERE o.f1 = 1234; one | f1
***************
*** 32,44 **** SELECT '' AS five, o.* FROM OID_TBL o WHERE o.f1 <> '1234'; five | f1
! ------+------------ | 1235 | 987
- | 4294966256 | 99999999 | 0
! (5 rows) SELECT '' AS three, o.* FROM OID_TBL o WHERE o.f1 <= '1234'; three | f1
--- 32,43 ---- SELECT '' AS five, o.* FROM OID_TBL o WHERE o.f1 <> '1234'; five | f1
! ------+---------- | 1235 | 987 | 99999999 | 0
! (4 rows) SELECT '' AS three, o.* FROM OID_TBL o WHERE o.f1 <= '1234'; three | f1
***************
*** 57,75 **** SELECT '' AS four, o.* FROM OID_TBL o WHERE o.f1 >= '1234'; four | f1
! ------+------------ | 1234 | 1235
- | 4294966256 | 99999999
! (4 rows) SELECT '' AS three, o.* FROM OID_TBL o WHERE o.f1 > '1234'; three | f1
! -------+------------ | 1235
- | 4294966256 | 99999999
! (3 rows) DROP TABLE OID_TBL;
--- 56,72 ---- SELECT '' AS four, o.* FROM OID_TBL o WHERE o.f1 >= '1234'; four | f1
! ------+---------- | 1234 | 1235 | 99999999
! (3 rows) SELECT '' AS three, o.* FROM OID_TBL o WHERE o.f1 > '1234'; three | f1
! -------+---------- | 1235 | 99999999
! (2 rows) DROP TABLE OID_TBL;
======================================================================
*** ./expected/geometry-powerpc-linux-gnulibc1.out Wed Sep 13 06:07:16 2000
--- ./results/geometry.out Thu Mar 22 16:01:20 2001
***************
*** 445,451 ****
-----+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
((-3,0),(-2.59807621135076,1.50000000000442),(-1.49999999999116,2.59807621135842),(1.53102359017709e-11,3),(1.50000000001768,2.59807621134311),(2.59807621136607,1.4999999999779),(3,-3.06204718035418e-11),(2.59807621133545,-1.50000000003094),(1.49999999996464,-2.59807621137373),(-4.59307077053127e-11,-3),(-1.5000000000442,-2.5980762113278),(-2.59807621138138,-1.49999999995138))
|
((-99,2),(-85.6025403783588,52.0000000001473),(-48.9999999997054,88.602540378614),(1.00000000051034,102),(51.0000000005893,88.6025403781036),(87.6025403788692,51.9999999992634),(101,1.99999999897932),(87.6025403778485,-48.0000000010313),(50.9999999988214,-84.6025403791243),(0.999999998468976,-98),(-49.0000000014732,-84.6025403775933),(-85.6025403793795,-47.9999999983795))
! |
((-4,3),(-3.33012701891794,5.50000000000737),(-1.49999999998527,7.3301270189307),(1.00000000002552,8),(3.50000000002946,7.33012701890518),(5.33012701894346,5.49999999996317),(6,2.99999999994897),(5.33012701889242,0.499999999948437),(3.49999999994107,-1.33012701895622),(0.999999999923449,-2),(-1.50000000007366,-1.33012701887966),(-3.33012701896897,0.500000000081027))
|
((-2,2),(-1.59807621135076,3.50000000000442),(-0.499999999991161,4.59807621135842),(1.00000000001531,5),(2.50000000001768,4.59807621134311),(3.59807621136607,3.4999999999779),(4,1.99999999996938),(3.59807621133545,0.499999999969062),(2.49999999996464,-0.598076211373729),(0.999999999954069,-1),(-0.500000000044197,-0.598076211327799),(-1.59807621138138,0.500000000048616))
|
((90,200),(91.3397459621641,205.000000000015),(95.0000000000295,208.660254037861),(100.000000000051,210),(105.000000000059,208.66025403781),(108.660254037887,204.999999999926),(110,199.999999999898),(108.660254037785,194.999999999897),(104.999999999882,191.339745962088),(99.9999999998469,190),(94.9999999998527,191.339745962241),(91.3397459620621,195.000000000162))
|
((0,0),(13.3974596216412,50.0000000001473),(50.0000000002946,86.602540378614),(100.00000000051,100),(150.000000000589,86.6025403781036),(186.602540378869,49.9999999992634),(200,-1.02068239345139e-09),(186.602540377848,-50.0000000010313),(149.999999998821,-86.6025403791243),(99.999999998469,-100),(49.9999999985268,-86.6025403775933),(13.3974596206205,-49.9999999983795))
--- 445,451 ----
-----+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
((-3,0),(-2.59807621135076,1.50000000000442),(-1.49999999999116,2.59807621135842),(1.53102359017709e-11,3),(1.50000000001768,2.59807621134311),(2.59807621136607,1.4999999999779),(3,-3.06204718035418e-11),(2.59807621133545,-1.50000000003094),(1.49999999996464,-2.59807621137373),(-4.59307077053127e-11,-3),(-1.5000000000442,-2.5980762113278),(-2.59807621138138,-1.49999999995138))
|
((-99,2),(-85.6025403783588,52.0000000001473),(-48.9999999997054,88.602540378614),(1.00000000051034,102),(51.0000000005893,88.6025403781036),(87.6025403788692,51.9999999992634),(101,1.99999999897932),(87.6025403778485,-48.0000000010313),(50.9999999988214,-84.6025403791243),(0.999999998468976,-98),(-49.0000000014732,-84.6025403775933),(-85.6025403793795,-47.9999999983795))
! |
((-4,3),(-3.33012701891794,5.50000000000737),(-1.49999999998527,7.3301270189307),(1.00000000002552,8),(3.50000000002946,7.33012701890518),(5.33012701894346,5.49999999996317),(6,2.99999999994897),(5.33012701889242,0.499999999948437),(3.49999999994107,-1.33012701895622),(0.999999999923449,-2),(-1.50000000007366,-1.33012701887967),(-3.33012701896897,0.500000000081028))
|
((-2,2),(-1.59807621135076,3.50000000000442),(-0.499999999991161,4.59807621135842),(1.00000000001531,5),(2.50000000001768,4.59807621134311),(3.59807621136607,3.4999999999779),(4,1.99999999996938),(3.59807621133545,0.499999999969062),(2.49999999996464,-0.598076211373729),(0.999999999954069,-1),(-0.500000000044197,-0.598076211327799),(-1.59807621138138,0.500000000048616))
|
((90,200),(91.3397459621641,205.000000000015),(95.0000000000295,208.660254037861),(100.000000000051,210),(105.000000000059,208.66025403781),(108.660254037887,204.999999999926),(110,199.999999999898),(108.660254037785,194.999999999897),(104.999999999882,191.339745962088),(99.9999999998469,190),(94.9999999998527,191.339745962241),(91.3397459620621,195.000000000162))
|
((0,0),(13.3974596216412,50.0000000001473),(50.0000000002946,86.602540378614),(100.00000000051,100),(150.000000000589,86.6025403781036),(186.602540378869,49.9999999992634),(200,-1.02068239345139e-09),(186.602540377848,-50.0000000010313),(149.999999998821,-86.6025403791243),(99.999999998469,-100),(49.9999999985268,-86.6025403775933),(13.3974596206205,-49.9999999983795))
======================================================================
Tatsuo Ishii <t-ishii@sra.co.jp> writes:
>> The bit test diffs seem to indicate that bit_cmp is messed up. That
>> depends on memcmp. I seem to recall something about memcmp not being
>> 8-bit-clean on SunOS ... does that ring a bell with anyone?
> Good point. From the man page of memcmp(3) on this machine:
> BUGS
> memcmp() uses native character comparison, which is signed
> on some machines and unsigned on other machines. Thus the
> sign of the value returned when one of the characters has
> its high-order bit set is implementation-dependent.
Eeek.
The C spec documents I have at hand all agree that memcmp, strcmp,
etc shall interpret their arguments as unsigned char. I hope Sun
were the only ones who took the above more liberal interpretation...
regards, tom lane
> Tatsuo Ishii <t-ishii@sra.co.jp> writes: > > For the regression test, I got 7 failures, most of them seem harmless, > > the only concern I have is bit test though. > > Most of the diffs derive from what I recall to be a known SunOS problem, > that strtol fails to notice overflow. A value that should be rejected > is getting inserted into int4_tbl (mod 2^32 of course). > > The bit test diffs seem to indicate that bit_cmp is messed up. That > depends on memcmp. I seem to recall something about memcmp not being > 8-bit-clean on SunOS ... does that ring a bell with anyone? Good point. From the man page of memcmp(3) on this machine: BUGS memcmp() uses native character comparison, which is signed on some machines and unsigned on other machines. Thus the sign of the value returned when one of the characters has its high-order bit set is implementation-dependent. -- Tatsuo Ishii
On Thu, Mar 22, 2001 at 07:58:04PM +0000, Patrick Welche wrote: > On Fri, Mar 23, 2001 at 06:25:50AM +1100, Giles Lean wrote: > > > > > PS: AFAIK geometry-positive-zeros-bsd works for all NetBSD platforms - the > > > above difference is only for i386 + fpu. > > > > It doesn't on NetBSD-1.5/alpha -- there geometry-positive-zeros is > > correct. > > Sorry, that should have read: > > AFAIK geometry-positive-zeros works for all NetBSD platforms - the > above difference is only for i386 + fpu. Seems that following patch is needed. Now It Works For Me (tm). Giles, does the regress test now succed for you? -- marko Index: src/test/regress/resultmap =================================================================== RCS file: /home/projects/pgsql/cvsroot/pgsql/src/test/regress/resultmap,v retrieving revision 1.45 diff -u -r1.45 resultmap --- src/test/regress/resultmap 2001/03/22 15:13:18 1.45 +++ src/test/regress/resultmap 2001/03/22 17:29:49 @@ -17,6 +17,7 @@ geometry/.*-openbsd=geometry-positive-zeros-bsd geometry/.*-irix6=geometry-irix geometry/.*-netbsd=geometry-positive-zeros +geometry/i.86-.*-netbsdelf1.5=geometry-positive-zeros-bsd geometry/.*-sysv5uw7.*:cc=geometry-uw7-cc geometry/.*-sysv5uw7.*:gcc=geometry-uw7-gcc geometry/alpha.*-dec-osf=geometry-alpha-precision
Vince Vielhaber <vev@michvhf.com> writes: > On 22 Mar 2001, Trond Eivind [iso-8859-1] Glomsrød wrote: > > > teg@redhat.com (Trond Eivind Glomsrød) writes: > > > > > Thomas Lockhart <lockhart@alumni.caltech.edu> writes: > > > > > > > If a platform you are running on is not listed, make sure it gets > > > > included! > > > > > > Red Hat Linux, Wolverine Beta (and some updates) - glibc 2.2.2, > > > 2.4.2ish kernel (read: lots of fixes), gcc 2.96RH: All 76 tests passed > > > with 7.1beta6 (parallel_schedule). > > > > Forgot to mention: This is x86. > > Forget to enter it into the regresstest database? > > http://www.postgresql.org/~vev/regress/ I was planning on waiting with that until I test it on an official release. -- Trond Eivind Glomsrød Red Hat, Inc.
On 23 Mar 2001, Trond Eivind [iso-8859-1] Glomsr�d wrote: > Vince Vielhaber <vev@michvhf.com> writes: > > > On 22 Mar 2001, Trond Eivind [iso-8859-1] Glomsr�d wrote: > > > > > teg@redhat.com (Trond Eivind Glomsr�d) writes: > > > > > > > Thomas Lockhart <lockhart@alumni.caltech.edu> writes: > > > > > > > > > If a platform you are running on is not listed, make sure it gets > > > > > included! > > > > > > > > Red Hat Linux, Wolverine Beta (and some updates) - glibc 2.2.2, > > > > 2.4.2ish kernel (read: lots of fixes), gcc 2.96RH: All 76 tests passed > > > > with 7.1beta6 (parallel_schedule). > > > > > > Forgot to mention: This is x86. > > > > Forget to enter it into the regresstest database? > > > > http://www.postgresql.org/~vev/regress/ > > I was planning on waiting with that until I test it on an official release. I figured that, it was my just smartass way of reminding EVERYONE to put their data in the database. I saw a few reports of things working yet there was nothing in the database saying so, it was only posted here. 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 ==========================================================================
> OpenBSD 2.8 x86 7.1 2001-03-22, Brandon. Palmer OBSD checks out for sparc and i386. We did need to make a change to the resultmap file to make the regression tests clean for the sparc. I have attached the diff. Also, on the sparc that i'm using (sparc4/110), make check takes 1950 seconds. Most of the time is spent in this test: parallel group (13 tests): float4 int2 int4 text name varchar oid boolean char float8 int8 bit numeric There is a long pause between 'bit' and 'numeric'. Same with on i386. Is this a problem that is local to obsd? Is it an expected delay? It works, but seems like a real perf problem. Anyway: ++++++++++++++++ Sparc 4/110, 64M, SCSI disk, OBSD 2.8 virgin ======================All 76 tests passed. ====================== 1941.34s real 130.23s user 93.77s system $ uname -a OpenBSD azreal 2.8 GENERIC#0 sparc ++++++++++++++++ P2 300, 96M, IDE Disk, OBSD 2.8 virgin ======================All 76 tests passed. ====================== 262.67s real 21.84s user 13.56s system $ uname -a OpenBSD orion 2.8 GENERIC#0 i386 ++++++++++++++++ I can't get tcl/tk working to same my life, but that's not too important for a release, just a config pain in the rear for obsd I guess. - brandon b. palmer, bpalmer@crimelabs.net pgp: www.crimelabs.net/bpalmer.pgp5
bpalmer <bpalmer@crimelabs.net> writes:
> seconds. Most of the time is spent in this test:
> parallel group (13 tests): float4 int2 int4 text name varchar oid boolean
> char float8 int8 bit numeric
> There is a long pause between 'bit' and 'numeric'. Same with on i386. Is
> this a problem that is local to obsd? Is it an expected delay?
Yes, that's the expected behavior. The 'numeric' test runs considerably
longer than most of the others. (It used to be even slower, but I made
Jan trim it down ;-))
regards, tom lane
Tom Lane writes: > The bit test diffs seem to indicate that bit_cmp is messed up. That > depends on memcmp. I seem to recall something about memcmp not being > 8-bit-clean on SunOS ... does that ring a bell with anyone? Sure enough: - Macro: AC_FUNC_MEMCMP If the `memcmp' function is not available, or does not work on 8-bit data (like the one onSunOS 4.1.3), add `memcmp.o' to output variable `LIBOBJS'. We could try to mangle this into doing the right thing for us. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
Tom Lane writes: > > and yet another run (and different results): > > > ================================================= > > 1 of 76 tests failed, 1 failed test(s) ignored. > > ================================================= > > That's just ye olde random "random" failure ... Actually, this is one real failed test plus the "random" failure. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane writes:
> =================================================
> 1 of 76 tests failed, 1 failed test(s) ignored.
> =================================================
>>
>> That's just ye olde random "random" failure ...
> Actually, this is one real failed test plus the "random" failure.
(Checks code...) Hm, you're right. May I suggest that this is a rather
confusing wording? Perhaps
1 of 76 tests failed, plus 1 failed test(s) ignored.
would be less likely to mislead people.
regards, tom lane
Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane writes:
>> The bit test diffs seem to indicate that bit_cmp is messed up. That
>> depends on memcmp. I seem to recall something about memcmp not being
>> 8-bit-clean on SunOS ... does that ring a bell with anyone?
> Sure enough:
> - Macro: AC_FUNC_MEMCMP
> If the `memcmp' function is not available, or does not work on
> 8-bit data (like the one on SunOS 4.1.3), add `memcmp.o' to output
> variable `LIBOBJS'.
> We could try to mangle this into doing the right thing for us.
Not sure if it's worth the trouble. That would be an AC_TRY_RUN test,
which you've been trying to move away from, no? It doesn't seem like
anyone still cares about SunOS 4.1.*, so ...
regards, tom lane
Hi all. Suddenly I obtain access to ULTRIX black 4.3 1 RISC I don't shure is it supported, but I see /src/include/port/ultrix4.h file so my guess is `yes, at least was'. I got last version from CVS and try configure && gmake it results in gcc -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../../src/include -c xlog.c -o xlog.o In file included from xlog.c:36: ../../../../src/include/storage/s_lock.h:88: warning: type defaults to `int' in declaration of `slock_t' ../../../../src/include/storage/s_lock.h:88: parse error before `*' ../../../../src/include/storage/s_lock.h:91: warning: type defaults to `int' in declaration of `slock_t' ../../../../src/include/storage/s_lock.h:91: parse error before `*' gmake[4]: *** [xlog.o] Error 1 grep of .h files shows that slock_t usualy defined in /src/include/port/*.h, but it is not defined in ultrix4.h and I can't find it in system includes. Regards, ASK
Alexander Klimov <ask@wisdom.weizmann.ac.il> writes:
> Suddenly I obtain access to
> ULTRIX black 4.3 1 RISC
Uh ... what kind of processor is that? Offhand I don't see any
indication that any of the entries in s_lock.h are supposed to work
for Ultrix.
regards, tom lane
Tom Lane <tgl@sss.pgh.pa.us> writes: > Alexander Klimov <ask@wisdom.weizmann.ac.il> writes: > > Suddenly I obtain access to > > ULTRIX black 4.3 1 RISC > > Uh ... what kind of processor is that? Offhand I don't see any > indication that any of the entries in s_lock.h are supposed to work > for Ultrix. The RISC/Ultrix machines ran (older) MIPS chips. Ultrix also ran (amazingly slowly) on the VAX architecture. [Fond memories of my first sysadmin job...] -Doug
> Alexander Klimov <ask@wisdom.weizmann.ac.il> writes:
>> Suddenly I obtain access to
>> ULTRIX black 4.3 1 RISC
> Uh ... what kind of processor is that? Offhand I don't see any
> indication that any of the entries in s_lock.h are supposed to work
> for Ultrix.
On closer look I notice that the putative support for machines without
a TEST_AND_SET implementation got broken by careless rearrangement of
the declarations in s_lock.h :-(. I have repaired this, and if you
update from CVS you should find that things compile.
However, you don't really want to run without TEST_AND_SET support;
it'll be dog-slow. Furthermore, the support for machines without
TEST_AND_SET is fairly new. I doubt it existed when the Ultrix port
was last reported to work. So the question above still stands.
I suspect that some one of the implementations in s_lock.h was intended
to be usable on Ultrix, and we've somehow dropped the declarations
needed to make it go. You might want to pull down an old tarball (6.3
or before) and look at how it compiles the s_lock support on Ultrix.
Please send in a patch if you find that one is necessary for s_lock
support on Ultrix.
regards, tom lane
The Hermit Hacker wrote:
>
> On Thu, 22 Mar 2001, Thomas Lockhart wrote:
>
> > Solaris x86 7.0 2000-04-12, Marc Fournier
> >
> > scrappy, do you still have this machine?
>
> Doing tests on Solaris x86/7 right now, will report as soon as they are
> done ...
>
> > Solaris 2.5.1-2.7 Sparc 7.0 2000-04-12, Peter Eisentraut
> >
> > I'll bet that someone already has Solaris covered. Report?
>
> Will do up Sparc/7 also this morning ...
In my tests on sparc/7 my compile died at line 3088 of
postgresql-7.1beta6/src/interfaces/python/pgmodule.c:
./pgmodule.c:3088: parse error before `init_pg'
That's line 3137 of today's (22Mar) snapshot, which reads:
/* Initialization function for the module */
DL_EXPORT(void)
init_pg(void)
{
I'm not a C expert by any means, but I can't figure how that is valid.
Given my ignorance, I don't want to call it a bug. Plus we don't use the
python module in production, nor the sparc platform. But it seemed worth
pointing out.
--
Karl
-----BEGIN PGP SIGNED MESSAGE----- On 22 Mar 2001, at 14:29, Thomas Lockhart wrote: > Linux 2.2.x armv4l 7.0 2000-04-17, Mark Knox Compiled and tested 7.1beta6 tonight. All the regression tests passed except two - the usual minor differences in geometry (rounding on the final digit) and this rather troubling output from type_sanity. I'm not altogether sure what impact this has. Everything seems to run just fine. *** ./expected/type_sanity.out Tue Sep 12 00:49:16 2000 - --- ./results/type_sanity.out Thu Mar 22 21:42:49 2001 *************** *** 172,177 **** p1.attalign != p2.typalign OR p1.attbyval != p2.typbyval); oid | attname | oid | typname ! -----+---------+-----+--------- ! (0 rows) - --- 172,239 ---- p1.attalign != p2.typalign OR p1.attbyval != p2.typbyval); oid | attname | oid | typname ! -------+---------+-----+--------- ! 16572 | ctid | 27 | tid ! 16593 | ctid | 27 | tid ! 16610 | ctid | 27 | tid ! 16635 | ctid | 27 | tid ! 16646 | ctid | 27 | tid ! 16678 | ctid | 27 | tid ! 16691 | ctid | 27 | tid ! 16873 | ctid | 27 | tid ! 16941 | ctid | 27 | tid ! 16953 | ctid | 27 | tid ! 16970 | ctid | 27 | tid ! 17038 | ctid | 27 | tid ! 17051 | ctid | 27 | tid ! 17067 | ctid | 27 | tid ! 17079 | ctid | 27 | tid ! 17090 | ctid | 27 | tid ! 17206 | ctid | 27 | tid ! 17221 | ctid | 27 | tid ! 17236 | ctid | 27 | tid ! 17251 | ctid | 27 | tid ! 17266 | ctid | 27 | tid ! 17281 | ctid | 27 | tid ! 17301 | ctid | 27 | tid ! 17314 | ctid | 27 | tid ! 17327 | ctid | 27 | tid ! 17342 | ctid | 27 | tid ! 17355 | ctid | 27 | tid ! 18792 | ctid | 27 | tid ! 18820 | ctid | 27 | tid ! 18832 | ctid | 27 | tid ! 18845 | ctid | 27 | tid ! 18857 | ctid | 27 | tid ! 18869 | ctid | 27 | tid ! 18888 | ctid | 27 | tid ! 18922 | ctid | 27 | tid ! 18937 | ctid | 27 | tid ! 18967 | ctid | 27 | tid ! 18990 | ctid | 27 | tid ! 19005 | ctid | 27 | tid ! 19019 | ctid | 27 | tid ! 19031 | ctid | 27 | tid ! 19042 | ctid | 27 | tid ! 19053 | ctid | 27 | tid ! 19069 | ctid | 27 | tid ! 19080 | ctid | 27 | tid ! 19103 | ctid | 27 | tid ! 20617 | ctid | 27 | tid ! 20633 | ctid | 27 | tid ! 20643 | ctid | 27 | tid ! 20655 | ctid | 27 | tid ! 20677 | ctid | 27 | tid ! 20689 | ctid | 27 | tid ! 20702 | ctid | 27 | tid ! 20716 | ctid | 27 | tid ! 20726 | ctid | 27 | tid ! 20766 | ctid | 27 | tid ! 20784 | ctid | 27 | tid ! 20794 | ctid | 27 | tid ! 20804 | ctid | 27 | tid ! 20836 | ctid | 27 | tid ! 20860 | ctid | 27 | tid ! 20879 | ctid | 27 | tid ! (62 rows) -----BEGIN PGP SIGNATURE----- Version: N/A iQCVAwUBOrrHrv+IdJuhyV9xAQGemgQApLVZS9xWQAtIzfgw3ILQThtEdftUBH20 FCoNqod++HunTazDwQZo6Msbunlvb8cJmSXg/kRkUmN6FQ39RtK9XEWsvFUy1+Nx eJCHiHyIMZBmmXNK1eiK0AyxFSqD8MKtgSuKvprXWNzTD4+NVZzWy9h1cONhZviN KEj9thVXQDc= =TG7n -----END PGP SIGNATURE-----
Marko Kreen writes: > OK: Linux 2.4.2 i686 / gcc 2.95.2 / Debian testing/unstable > > no problems. > > OK?: NetBSD 1.5 i586 / egcs 2.91.66 / (netbsd-1-5 from Jan) > > netbsd FAILED the geometry test, diff attached, dunno if its > critical or not. Can you check whether it matches any of the other possible geometry results? See http://www.postgresql.org/devel-corner/docs/postgres/regress-platform.html about the mechanisms. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
"Mark Knox" <segfault@hardline.org> writes:
>> Linux 2.2.x armv4l 7.0 2000-04-17, Mark Knox
> Compiled and tested 7.1beta6 tonight. All the regression tests passed
> except two - the usual minor differences in geometry (rounding on the
> final digit) and this rather troubling output from type_sanity.
Most bizarre --- and definitely indicative of trouble. Would you send
along the output of this query in that database:
select p1.oid,attrelid,relname,attname,attlen,attalign,attbyval
from pg_attribute p1, pg_class p2
where atttypid = 27 and p2.oid = attrelid
order by 1;
regards, tom lane
Does that database have any user-created relations in it, or is it
just a virgin database? It seems that the wrong attlen is being
computed for ctid fields during bootstrap, but the regression test
output (if it was complete) implies that the value inserted for
user-created fields was OK. This doesn't make a lot of sense since
it's the same code...
regards, tom lane
-----BEGIN PGP SIGNED MESSAGE----- On 25 Mar 2001, at 15:02, Tom Lane wrote: > > (rounding on the final digit) and this rather troubling output from > > type_sanity. > > Most bizarre --- and definitely indicative of trouble. Would you send > along the output of this query in that database: > > select p1.oid,attrelid,relname,attname,attlen,attalign,attbyval > from pg_attribute p1, pg_class p2 > where atttypid = 27 and p2.oid = attrelid > order by 1; I was afraid of that ;) Here's the output: [PostgreSQL 7.1beta6 on armv4l-unknown-linux-gnuoldld, compiled by GCC 2.95.1] type \? for help on slash commands type \q to quit type \g or terminate with semicolon to execute queryYou are currentlyconnected to the database: postgres postgres=> select p1.oid,attrelid,relname,attname,attlen,attalign,attbyval from pg_attribute p1, pg_class p2 where atttypid = 27 and p2.oid = attrelid order by 1; oid|attrelid|relname |attname|attlen|attalign|attbyval - -----+--------+--------------+-------+------+--------+-------- 16401| 1247|pg_type |ctid | 6|i |f 16415| 1262|pg_database |ctid | 6|i |f 16439| 1255|pg_proc |ctid | 6|i |f 16454| 1260|pg_shadow |ctid | 6|i |f 16464| 1261|pg_group |ctid | 6|i |f 16486| 1249|pg_attribute |ctid | 6|i |f 16515| 1259|pg_class |ctid | 6|i |f 16526| 1215|pg_attrdef |ctid | 6|i |f 16537| 1216|pg_relcheck |ctid | 6|i |f 16557| 1219|pg_trigger |ctid | 6|i |f 16572| 16567|pg_inherits |ctid | 8|i |f 16593| 16579|pg_index |ctid | 8|i |f 16610| 16600|pg_statistic |ctid | 8|i |f 16635| 16617|pg_operator |ctid | 8|i |f 16646| 16642|pg_opclass |ctid | 8|i |f 16678| 16653|pg_am |ctid | 8|i |f 16691| 16685|pg_amop |ctid | 8|i |f 16873| 16867|pg_amproc |ctid | 8|i |f 16941| 16934|pg_language |ctid | 8|i |f 16953| 16948|pg_largeobject|ctid | 8|i |f 16970| 16960|pg_aggregate |ctid | 8|i |f 17038| 17033|pg_ipl |ctid | 8|i |f 17051| 17045|pg_inheritproc|ctid | 8|i |f 17067| 17058|pg_rewrite |ctid | 8|i |f 17079| 17074|pg_listener |ctid | 8|i |f 17090| 17086|pg_description|ctid | 8|i |f 17206| 17201|pg_toast_1215 |ctid | 8|i |f 17221| 17216|pg_toast_17086|ctid | 8|i |f 17236| 17231|pg_toast_1255 |ctid | 8|i |f 17251| 17246|pg_toast_1216 |ctid | 8|i |f 17266| 17261|pg_toast_17058|ctid | 8|i |f 17281| 17276|pg_toast_16600|ctid | 8|i |f 17301| 17291|pg_user |ctid | 8|i |f 17314| 17309|pg_rules |ctid | 8|i |f 17327| 17322|pg_views |ctid | 8|i |f 17342| 17335|pg_tables |ctid | 8|i |f 17355| 17350|pg_indexes |ctid | 8|i |f (37 rows) -----BEGIN PGP SIGNATURE----- Version: N/A iQCVAwUBOr5XA/+IdJuhyV9xAQGfOgP6ApV6ia44bxCo/KyIE20knn/1FTysECW9 Rq9mLDhpYKHYtTWz1cgGtxzCEiRAMN+ZuO7u5nydy6TB8dp8iCd9eLAro4GAzqYM aD9V9S3nK3YwV9RaKBWJqHXNPI5enp19YS74GxN0f9VIw/4PXlYVm2tQJLVWNGs+ lFfQnraYEZQ= =Cj2l -----END PGP SIGNATURE-----
On Wed, 21 Mar 2001, Thomas Lockhart wrote: > OK, here is my current platform list taken from the -hackers list and > from Vince's web page. I'm sure I've missed at least a few reports, but > please confirm that platforms are actually running and passing > regression tests with recent betas or the latest release candidate. Updates... > Linux 2.2.x Alpha 7.1 2001-01-23, Ryan Kirkpatrick Tested RC1 with 2.2.17 on my XLT366 Alpha, all regression tests passed. > Linux 2.2.15 Sparc 7.1 2001-01-30, Ryan Kirkpatrick Tested RC1 with 2.2.18 on my Sparc 20 (SM51), all regression tests passed. Both have been entered into the regression database on the website as well. TTYL. --------------------------------------------------------------------------- | "For to me to live is Christ, and to die is gain." | | --- Philippians 1:21 (KJV) | --------------------------------------------------------------------------- | Ryan Kirkpatrick | Boulder, Colorado | http://www.rkirkpat.net/ | ---------------------------------------------------------------------------
Two more for the list (not a single regression test failing, which is a first on Alpha!) Tru64 4.0G Alpha cc-v6.3-129 7.1 2001-03-28 Tru64 4.0G Alpha gcc-2.95.1 7.1 2001-03-28 I updated the regression test database as well. Adriaan
> >> Suddenly I obtain access to
> >> ULTRIX black 4.3 1 RISC
> > Uh ... what kind of processor is that? Offhand I don't see any
> > indication that any of the entries in s_lock.h are supposed to work
> > for Ultrix.
As mentioned earlier, Ultrix on RISC means that it is a MIPS processor.
DEC implemented OSF-1 for their Alpha processors.
> I suspect that some one of the implementations in s_lock.h was intended
> to be usable on Ultrix, and we've somehow dropped the declarations
> needed to make it go. You might want to pull down an old tarball (6.3
> or before) and look at how it compiles the s_lock support on Ultrix.
Any hints for Alexander on how to do it *if* it is a MIPS processor?
- Thomas
The list of unreported or "in progress" platforms has gotten much
shorter. If anyone can help on the remaining problems, we'll be able to
move closer to release status, which is A Good Thing (tm) ;)
btw, if we get most of these qualified, we will be on around 30
platforms!!!!
- Thomas
Unreported or problem platforms:
Linux 2.0.x MIPS 7.0 2000-04-13, Tatsuo Ishii
Tatsuo's machine has died. Anyone else with a Cobalt?
mklinux PPC750 7.0 2000-04-13, Tatsuo Ishii
Any luck with RC1?
NetBSD m68k 7.0 2000-04-10, Henry B. Hotz
NetBSD Sparc 7.0 2000-04-13, Tom I. Helbekkmo
We need some NetBSD folks to speak up! Also, there are several flavors
of OpenBSD which are not represented in our list, but which probably are
already running PostgreSQL. Anyone?
QNX 4.25 x86 7.0 2000-04-01, Dr. Andreas Kardos
Does QNX get demoted to the "unsupported list"? It is known to have
problems with 7.1, right?
Solaris x86 7.0 2000-04-12, Marc Fournier
scrappy, did you work through the tests yet?
Ultrix MIPS 7.1 2001-??-??, Alexander Klimov
Any possibilities here?
And here are the up-to-date platforms; thanks for the reports:
AIX 4.3.3 RS6000 7.1 2001-03-21, Gilles Darold
BeOS 5.0.3 x86 7.1 2000-12-18, Cyril Velter
BSDI 4.01 x86 7.1 2001-03-19, Bruce Momjian
Compaq Tru64 4.0g Alpha 7.1 2001-03-19, Brent Verner
FreeBSD 4.3 x86 7.1 2001-03-19, Vince Vielhaber
HPUX PA-RISC 7.1 2001-03-19, 10.20 Tom Lane, 11.00 Giles Lean
IRIX 6.5.11 MIPS 7.1 2001-03-22, Robert Bruccoleri
Linux 2.2.x Alpha 7.1 2001-01-23, Ryan Kirkpatrick
Linux 2.2.x armv4l 7.1 2001-03-22, Mark Knox
Linux 2.2.18 PPC750 7.1 2001-03-19, Tom Lane
Linux 2.2.x S/390 7.1 2000-11-17, Neale Ferguson
Linux 2.2.15 Sparc 7.1 2001-01-30, Ryan Kirkpatrick
Linux 2.2.16 x86 7.1 2001-03-19, Thomas Lockhart
MacOS X Darwin PPC 7.1 2000-12-11, Peter Bierman
NetBSD 1.5 alpha 7.1 2001-03-22, Giles Lean
NetBSD 1.5E arm32 7.1 2001-03-21, Patrick Welche
NetBSD 1.5S x86 7.1 2001-03-21, Patrick Welche
OpenBSD 2.8 x86 7.1 2001-03-22, Brandon Palmer
SCO OpenServer 5 x86 7.1 2001-03-13, Billy Allie
SCO UnixWare 7.1.1 x86 7.1 2001-03-19, Larry Rosenman
Solaris 2.7 Sparc 7.1 2001-03-22, Marc Fournier
SunOS 4.1.4 Sparc 7.1 2001-03-23, Tatsuo Ishii
Windows/Win32 x86 7.1 2001-03-26, Magnus Hagander (clients only)
WinNT/Cygwin x86 7.1 2001-03-16, Jason Tishler
Thomas Lockhart writes: > SCO OpenServer 5 x86 7.1 2001-03-13, Billy Allie Where did you see this? I don't find it in the archives or in Vince's database. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
> > SCO OpenServer 5 x86 7.1 2001-03-13, Billy Allie
> Where did you see this? I don't find it in the archives or in Vince's
> database.
In FAQ_SCO. I was looking to try to figure out what the differences were
between the SCO products :)
- Thomas
Since the SCO UDK works on both UnixWare and OpenServer, I think we are pretty safe. Also, there was a post to -HACKERS about the accept bug and we changed the workaround to include OSR5. I'd leave it until disproved. I don't have a OSR5 installation to check it with, however. LER >>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<< On 3/26/01, 12:05:55 PM, Thomas Lockhart <lockhart@alumni.caltech.edu> wrote regarding Re: [HACKERS] Re: Call for platforms: > > > SCO OpenServer 5 x86 7.1 2001-03-13, Billy Allie > > Where did you see this? I don't find it in the archives or in Vince's > > database. > In FAQ_SCO. I was looking to try to figure out what the differences were > between the SCO products :) > - Thomas > ---------------------------(end of broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
> Linux 2.2.18 PPC750 7.1 2001-03-19, Tom Lane
"PPC750"? What's that? "PPC G3" might be more likely to mean something
to onlookers ...
regards, tom lane
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
> As mentioned earlier, Ultrix on RISC means that it is a MIPS processor.
>> I suspect that some one of the implementations in s_lock.h was intended
>> to be usable on Ultrix, and we've somehow dropped the declarations
>> needed to make it go. You might want to pull down an old tarball (6.3
>> or before) and look at how it compiles the s_lock support on Ultrix.
> Any hints for Alexander on how to do it *if* it is a MIPS processor?
Not sure. The only info I see in s_lock.h is in the "SGI" section:
* This stuff may be supplemented in the future with Masato Kataoka's MIPS-II* assembly from his NECEWS SVR4 port, but
weprobably ought to retain this* for the R3000 chips out there.
That name doesn't ring a bell with me --- anyone remember what code is
being referred to here, or where we might find Masato Kataoka?
MIPS-II code may or may not be compatible with Alexander's machine
anyway, but it's the only starting point I see.
Anyway, the last CVS update to port/ultrix.h that appears to have come
from someone actually using Ultrix was rev 1.2 on 7-May-97, which
predates the very existence of s_lock.h as a separate file. So I'd
definitely advise Alexander to find a tarball from that era and look at
how Ultrix was handled then.
I dunno if we even have tarballs from that far back on-line ... I
suppose another possibility is a date-based pull from the CVS server.
regards, tom lane
Thomas Lockhart writes: > > > SCO OpenServer 5 x86 7.1 2001-03-13, Billy Allie > > Where did you see this? I don't find it in the archives or in Vince's > > database. > > In FAQ_SCO. I was looking to try to figure out what the differences were > between the SCO products :) I wouldn't necessarily count something dated Oct 9, 2000. That was half a year ago, and even two months before beta. And the message doesn't actually say it worked. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
> "PPC750"? What's that? "PPC G3" might be more likely to mean something
> to onlookers ...
Actually "G3" means nothing outside of Apple afaict. The 750 series is a
follow-on to the 60x series, and there is a 7xxx series also. From my
pov, using an accepted label, rather than a marketing (re)label, better
indicates *what* this actually can run on. I'm not sure that I have it
labeled correctly yet, but "G3" is not a step in the right direction.
As we both found, it is difficult to wade through Apple's own docs to
decipher which processor is actually built into the system.
Should I put "Mac G3" in the comment section?
- Thomas
> > As mentioned earlier, Ultrix on RISC means that it is a MIPS processor.
> > Any hints for Alexander on how to do it *if* it is a MIPS processor?
> Not sure. The only info I see in s_lock.h is in the "SGI" section:
> * This stuff may be supplemented in the future with Masato Kataoka's MIPS-II
> * assembly from his NECEWS SVR4 port, but we probably ought to retain this
> * for the R3000 chips out there.
> That name doesn't ring a bell with me --- anyone remember what code is
> being referred to here, or where we might find Masato Kataoka?
I'm not remembering either...
> MIPS-II code may or may not be compatible with Alexander's machine
> anyway, but it's the only starting point I see.
The Ultrix machine is more likely to be a 2000- or 3000-series (older)
processor.
> Anyway, the last CVS update to port/ultrix.h that appears to have come
> from someone actually using Ultrix was rev 1.2 on 7-May-97, which
> predates the very existence of s_lock.h as a separate file. So I'd
> definitely advise Alexander to find a tarball from that era and look at
> how Ultrix was handled then.
> I dunno if we even have tarballs from that far back on-line ... I
> suppose another possibility is a date-based pull from the CVS server.
What can we help with Alex?
- Thomas
> > > > SCO OpenServer 5 x86 7.1 2001-03-13, Billy Allie
> > > Where did you see this? I don't find it in the archives or in Vince's
> > > database.
> > In FAQ_SCO. I was looking to try to figure out what the differences were
> > between the SCO products :)
> I wouldn't necessarily count something dated Oct 9, 2000. That was half a
> year ago, and even two months before beta. And the message doesn't
> actually say it worked.
?? I can see I was thrown off by the "last updated:" line near the top
of the file. It actually comes from a CVS commit, not from an explicit
update of the info in the file.
Very bad :(
- Thomas
I would..... LER -- 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 US >>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<< On 3/26/01, 2:36:19 PM, Thomas Lockhart <lockhart@alumni.caltech.edu> wrote regarding Re: [HACKERS] Re: Call for platforms: > > "PPC750"? What's that? "PPC G3" might be more likely to mean something > > to onlookers ... > Actually "G3" means nothing outside of Apple afaict. The 750 series is a > follow-on to the 60x series, and there is a 7xxx series also. From my > pov, using an accepted label, rather than a marketing (re)label, better > indicates *what* this actually can run on. I'm not sure that I have it > labeled correctly yet, but "G3" is not a step in the right direction. > As we both found, it is difficult to wade through Apple's own docs to > decipher which processor is actually built into the system. > Should I put "Mac G3" in the comment section? > - Thomas > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly
Karl DeBisschop <kdebisschop@range.infoplease.com> writes:
> In my tests on sparc/7 my compile died at line 3088 of
> postgresql-7.1beta6/src/interfaces/python/pgmodule.c:
> ./pgmodule.c:3088: parse error before `init_pg'
> That's line 3137 of today's (22Mar) snapshot, which reads:
> /* Initialization function for the module */
> DL_EXPORT(void)
> init_pg(void)
> {
What version of Python are you using? In Python 1.5, I find this
in Python.h:
#ifndef DL_EXPORT /* declarations for DLL import/export */
#define DL_EXPORT(RTYPE) RTYPE
#endif
which should make the above work.
regards, tom lane
Hi Is there a list somewhere listing the platforms 7.1 is being tested on right now? I'd be able to run regression tests on the following platforms, if necessary: FreeBSD 3.3 (x86) FreeBSD 4.2 (x86) Linux (x86 - 2.2 & 2.4 kernels, Redhat & Debian distro's) Solaris 7 (SPARC) Solaris8 (x86) Solaris 8 (SPARC) IRIX 6.2 IRIX 6.5 If I can get the box back to working order, Alpha Linux is also an option. I'd be willing to build binary packages for Solaris and IRIX. Regards, Mathijs -- "Books constitute capital." Thomas Jefferson
Thomas Lockhart wrote: > Linux 2.2.x Alpha 7.1 2001-01-23, Ryan Kirkpatrick > Linux 2.2.x armv4l 7.1 2001-03-22, Mark Knox > Linux 2.2.18 PPC750 7.1 2001-03-19, Tom Lane > Linux 2.2.x S/390 7.1 2000-11-17, Neale Ferguson > Linux 2.2.15 Sparc 7.1 2001-01-30, Ryan Kirkpatrick > Linux 2.2.16 x86 7.1 2001-03-19, Thomas Lockhart Did you get the message from Trond about Linux 2.4 x86? I can also verify all tests passed on a RedHat Public Beta installation with kernel 2.4. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Lamar Owen <lamar.owen@wgcr.org> writes: > Thomas Lockhart wrote: > > Linux 2.2.x Alpha 7.1 2001-01-23, Ryan Kirkpatrick > > Linux 2.2.x armv4l 7.1 2001-03-22, Mark Knox > > Linux 2.2.18 PPC750 7.1 2001-03-19, Tom Lane > > Linux 2.2.x S/390 7.1 2000-11-17, Neale Ferguson > > Linux 2.2.15 Sparc 7.1 2001-01-30, Ryan Kirkpatrick > > Linux 2.2.16 x86 7.1 2001-03-19, Thomas Lockhart > > Did you get the message from Trond about Linux 2.4 x86? I can also > verify all tests passed on a RedHat Public Beta installation with kernel > 2.4. I haven't put those in the list yet... I'll wait until we release a product, and test it on that. -- Trond Eivind Glomsrød Red Hat, Inc.
> Did you get the message from Trond about Linux 2.4 x86? I can also
> verify all tests passed on a RedHat Public Beta installation with kernel
> 2.4.
Trond had indicated that it was a 2.4.2 kernel with lots 'o patches, so
I figured I'd show the released stuff for now. I mentioned 2.4.2 in the
comments section.
- Thomas
On Tue, 27 Mar 2001, Mathijs Brands wrote: > Hi > > Is there a list somewhere listing the platforms 7.1 is being > tested on right now? I'd be able to run regression tests on > the following platforms, if necessary: > > FreeBSD 3.3 (x86) > FreeBSD 4.2 (x86) > Linux (x86 - 2.2 & 2.4 kernels, Redhat & Debian distro's) > Solaris 7 (SPARC) > Solaris 8 (x86) > Solaris 8 (SPARC) > IRIX 6.2 > IRIX 6.5 > > If I can get the box back to working order, Alpha Linux is > also an option. I'd be willing to build binary packages for > Solaris and IRIX. Check out the Developer's Corner on the website. It's at the top of the page. 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 Mon, Mar 26, 2001 at 05:41:31PM -0500, Vince Vielhaber allegedly wrote: > On Tue, 27 Mar 2001, Mathijs Brands wrote: > > Hi > > > > Is there a list somewhere listing the platforms 7.1 is being > > tested on right now? I'd be able to run regression tests on > > the following platforms, if necessary: > > > > FreeBSD 3.3 (x86) > > FreeBSD 4.2 (x86) > > Linux (x86 - 2.2 & 2.4 kernels, Redhat & Debian distro's) > > Solaris 7 (SPARC) > > Solaris 8 (x86) > > Solaris 8 (SPARC) > > IRIX 6.2 > > IRIX 6.5 > > > > If I can get the box back to working order, Alpha Linux is > > also an option. I'd be willing to build binary packages for > > Solaris and IRIX. > > Check out the Developer's Corner on the website. It's at the > top of the page. > > Vince. I had a look at it, but that surely can't be the complete list. There are only 20 results listed... Mathijs -- "Where is human nature so weak as in a bookstore!" Henry Ward Beecher (1813-1887)
Trond Eivind Glomsrød wrote: > Lamar Owen <lamar.owen@wgcr.org> writes: > > Did you get the message from Trond about Linux 2.4 x86? I can also > > verify all tests passed on a RedHat Public Beta installation with kernel > > 2.4. > I haven't put those in the list yet... I'll wait until we release a > product, and test it on that. Ah. Ok. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Mathijs Brands wrote: > > Hi > > Is there a list somewhere listing the platforms 7.1 is being > tested on right now? I'd be able to run regression tests on > the following platforms, if necessary: http://www.postgresql.org/devel-corner/docs/admin/supported-platforms.html is close to up to date (I made a few changes this morning). http://www.postgresql.org/~vev/regress/ is an on-line display and data entry page, which I have not managed yet to use in my development workflow. So I hope to look at it occasionally, but the -hackers mailing list is where I get most of my info. > FreeBSD 3.3 (x86) > FreeBSD 4.2 (x86) 4.3 (and I think 4.2) is covered already. > Linux (x86 - 2.2 & 2.4 kernels, Redhat & Debian distro's) Linux on x86 is pretty well covered, but we welcome additional tests and tests on as many variants as possible. > Solaris 7 (SPARC) > Solaris 8 (x86) > Solaris 8 (SPARC) Tests on Solaris 8, both Sparc and x86, would be very helpful. No reports so far, afaik. > IRIX 6.2 > IRIX 6.5 Irix 6.5.11 has been reported recently. But additional tests and testers would be a good thing, since there aren't that many in the -hacker community at the moment. > If I can get the box back to working order, Alpha Linux is > also an option. I'd be willing to build binary packages for > Solaris and IRIX. Alpha Linux is covered at the moment. Binary packages would be great. Thanks for the help! Regards. - Thomas
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
>> Anyway, the last CVS update to port/ultrix.h that appears to have come
>> from someone actually using Ultrix was rev 1.2 on 7-May-97, which
>> predates the very existence of s_lock.h as a separate file. So I'd
>> definitely advise Alexander to find a tarball from that era and look at
>> how Ultrix was handled then.
>> I dunno if we even have tarballs from that far back on-line ... I
>> suppose another possibility is a date-based pull from the CVS server.
> What can we help with Alex?
After digging around in the old code I have to retract my opinion that
a test-and-set implementation used to exist for MIPS. The code did
have SysV-semaphore-based support for machines without test-and-set,
and undoubtedly that's what was used on the old Ultrix port. (The
non-test-and-set code was broken for awhile, but I'd forgotten that
it formerly worked.)
The non-test-and-set case should work again in current CVS, and I'd
appreciate it if Alexander would verify that. But as far as getting
some test-and-set support for MIPS goes, it looks like the only way
is for someone to sit down with a MIPS assembly manual. I haven't
got one, nor access to a machine to test on...
regards, tom lane
> >NetBSD m68k 7.0 2000-04-10, Henry B. Hotz
> I no longer have a 68k machine that's fast enough to reasonably test
> PG on. I have a IIcx that sometimes serves as a router, but I'm
> using some second-generation powermac's mostly now. (You still have
> that Centris in your closet Tom?)
Oof. With its giant 250MB hard disk. I'm not likely to ever get that
going ;)
> I *did* just get MacOS X this weekend though and if I get it working
> on my work G4 maybe I could give it a try there.
It will require at least the second Darwin beta release to work.
- Thomas
On Mon, Mar 26, 2001 at 06:35:59PM -0500, Tom Lane allegedly wrote: > Thomas Lockhart <lockhart@alumni.caltech.edu> writes: > >> Anyway, the last CVS update to port/ultrix.h that appears to have come > >> from someone actually using Ultrix was rev 1.2 on 7-May-97, which > >> predates the very existence of s_lock.h as a separate file. So I'd > >> definitely advise Alexander to find a tarball from that era and look at > >> how Ultrix was handled then. > >> I dunno if we even have tarballs from that far back on-line ... I > >> suppose another possibility is a date-based pull from the CVS server. > > > What can we help with Alex? > > After digging around in the old code I have to retract my opinion that > a test-and-set implementation used to exist for MIPS. The code did > have SysV-semaphore-based support for machines without test-and-set, > and undoubtedly that's what was used on the old Ultrix port. (The > non-test-and-set code was broken for awhile, but I'd forgotten that > it formerly worked.) > > The non-test-and-set case should work again in current CVS, and I'd > appreciate it if Alexander would verify that. But as far as getting > some test-and-set support for MIPS goes, it looks like the only way > is for someone to sit down with a MIPS assembly manual. I haven't > got one, nor access to a machine to test on... I've got access to an Indigo² (IRIX 6.5, MIPS R10000), another Indigo² (IRIX 6.2, MIPS R4400) and a DECStation (NetBSD 1.?, MIPS R3000). The DECStation (also known as PMAX) originally ran Ultrix. If anybody has some code that needs testing, I'd be more than willing. However, if test-and-set works anything like I imagine, we really need to test it on a multi-cpu MIPS machine. A good starting point might be the test-and-set code in the NetBSD and Linux MIPS kernels. Btw. Everything you never wanted to know about the MIPS architecture: http://www.mips.com/Documentation/ Cheers, Mathijs -- "A book is a fragile creature. It suffers the wear of time,it fears rodents, the elements, clumsy hands." UmbertoEco
> The non-test-and-set case should work again in current CVS, and I'd
> appreciate it if Alexander would verify that. But as far as getting
> some test-and-set support for MIPS goes, it looks like the only way
> is for someone to sit down with a MIPS assembly manual. I haven't
> got one, nor access to a machine to test on...
That is not already available from the Irix support code?
- Thomas
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
> That is not already available from the Irix support code?
What we have for IRIX is
#if defined(__sgi)
/** SGI IRIX 5* slock_t is defined as a unsigned long. We use the standard SGI* mutex API.** The following comment is
leftfor historical reasons, but is probably* not a good idea since the mutex ABI is supported.** This stuff may be
supplementedin the future with Masato Kataoka's MIPS-II* assembly from his NECEWS SVR4 port, but we probably ought to
retainthis* for the R3000 chips out there.*/
#include "mutex.h"
#define TAS(lock) (test_and_set(lock,1))
#define S_UNLOCK(lock) (test_then_and(lock,0))
#define S_INIT_LOCK(lock) (test_then_and(lock,0))
#define S_LOCK_FREE(lock) (test_then_add(lock,0) == 0)
#endif /* __sgi */
Doesn't look to me like it's likely to work on anything but IRIX ...
regards, tom lane
Thomas Lockhart <lockhart@alumni.caltech.edu> writes: >> "PPC750"? What's that? "PPC G3" might be more likely to mean something >> to onlookers ... > Actually "G3" means nothing outside of Apple afaict. The 750 series is a > follow-on to the 60x series, and there is a 7xxx series also. From my > pov, using an accepted label, rather than a marketing (re)label, better > indicates *what* this actually can run on. I'm not sure that I have it > labeled correctly yet, but "G3" is not a step in the right direction. I found an apparently current "PowerPC CPU Summary" at http://e-www.motorola.com/webapp/sps/technology/tech_tutorial.jsp?catId=M943030621280 If accurate, the chip in this PowerBook is *not* a 750, since that tops out at 400 MHz. Apple offered this model in 400 and 500 MHz speeds, which makes it either a 7400 or 7410 chip ... > Should I put "Mac G3" in the comment section? Yes, if you won't put it where it should be ;-). I'm still of the opinion that "G3" will mean something to a vastly larger population than "750" or "7400" would. The latter are "marketing relabels" too you know; Motorola's internal designation would probably be something else entirely. regards, tom lane
Hi, I tested Solaris 8 SPARC (32 bit) over the weekend, and can test Solaris 8 INTEL this week/weekend. The results of Solaris 8 SPARC were in Vince's database last time I checked. ??? + Justin Mathijs Brands wrote: > > Hi > > Is there a list somewhere listing the platforms 7.1 is being > tested on right now? I'd be able to run regression tests on > the following platforms, if necessary: > > FreeBSD 3.3 (x86) > FreeBSD 4.2 (x86) > Linux (x86 - 2.2 & 2.4 kernels, Redhat & Debian distro's) > Solaris 7 (SPARC) > Solaris 8 (x86) > Solaris 8 (SPARC) > IRIX 6.2 > IRIX 6.5 > > If I can get the box back to working order, Alpha Linux is > also an option. I'd be willing to build binary packages for > Solaris and IRIX. > > Regards, > > Mathijs > -- > "Books constitute capital." > Thomas Jefferson > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly
I know that Sourceforge has been adding all sorts of machines to their compile farm. Maybe it would be worthwhile taking a look if they have platforms we don't? Regards and best wishes, Justin Clift Thomas Lockhart wrote: > > > The non-test-and-set case should work again in current CVS, and I'd > > appreciate it if Alexander would verify that. But as far as getting > > some test-and-set support for MIPS goes, it looks like the only way > > is for someone to sit down with a MIPS assembly manual. I haven't > > got one, nor access to a machine to test on... > > That is not already available from the Irix support code? > > - Thomas > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
On Tue, Mar 27, 2001 at 12:01:24PM +1000, Justin Clift allegedly wrote: > I know that Sourceforge has been adding all sorts of machines to their > compile farm. > > Maybe it would be worthwhile taking a look if they have platforms we > don't? > > Regards and best wishes, > > Justin Clift Compaq also still hands out free test accounts on Digital servers running Linux, Tru64 and FreeBSD... I think it's called the Testdrive program. Cheers, Mathijs -- It's not that perl programmers are idiots, it's that the language rewards idiotic behavior in a way that no other language or tool has ever done. Erik Naggum
Regression test on FBSD 3.3 & 4.2, IRIX 6.5 (was Re: Re: Call for platforms)
From
Mathijs Brands
Date:
On Mon, Mar 26, 2001 at 07:09:38PM -0500, Tom Lane allegedly wrote:
> Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
> > That is not already available from the Irix support code?
>
> What we have for IRIX is
>
> #if defined(__sgi)
> /*
> * SGI IRIX 5
> * slock_t is defined as a unsigned long. We use the standard SGI
> * mutex API.
> *
> * The following comment is left for historical reasons, but is probably
> * not a good idea since the mutex ABI is supported.
> *
> * This stuff may be supplemented in the future with Masato Kataoka's MIPS-II
> * assembly from his NECEWS SVR4 port, but we probably ought to retain this
> * for the R3000 chips out there.
> */
> #include "mutex.h"
> #define TAS(lock) (test_and_set(lock,1))
> #define S_UNLOCK(lock) (test_then_and(lock,0))
> #define S_INIT_LOCK(lock) (test_then_and(lock,0))
> #define S_LOCK_FREE(lock) (test_then_add(lock,0) == 0)
> #endif /* __sgi */
>
> Doesn't look to me like it's likely to work on anything but IRIX ...
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
I just tried to compile 7.1RC1 on my IRIX 6.5 box using gcc 2.95.2.
Appearently gcc chokes on some assembly in src/backend/storage/buffer/s_lock.c
(tas_dummy on line 235 to be precise).
Here's the offending code:
#if defined(__mips__)
static void
tas_dummy()
{ __asm__ _volatile__( "\
.global tas \n\
tas: \n\ .frame $sp, 0, $31 \n\
ll $14, 0($4) \n\ or $15, $14, 1 \n\
sc $15, 0($4) \n\ beq $15, 0, fail\n\
bne $14, 0, fail\n\ li $2, 0 \n\ .livereg
0x2000FF0E,0x00000FFF \n\ j $31 \n\
fail: \n\ li $2, 1 \n\
j $31 \n\
");
}
Notice the single underscore before volatile. I just checked the CVS
version of s_lock.c and this is still not fixed. Fixing this causes
as (the SGI version, not GNU as) to choke on the '.global tas' statement.
s_lock.c: At top level:
s_lock.c:234: warning: `tas_dummy' defined but not used
as: Error: /var/tmp/ccoUdrOb.s, line 421: undefined assembler operation: .global .global tas
gmake[4]: *** [s_lock.o] Error 1
Commenting out the .global statements does produce a binary, but it can't
complete the regression test due to other problems.
IpcSemaphoreCreate: semctl(id=0, 0, SETALL, ...) failed: Bad address
I'll see if I can come up with a solution for the .global and the
semaphore problem. I'll check wether pgsql 7.0 does run on this box too.
One wonders how Robert Bruccoleri did get 7.1RC1 to work properly. I'll
check the archive for clues.
On my FreeBSD 4.2 box 7.1RC1 runs flawlessly. I've also tested the CVS
version a few days ago on a 4.1.1 box without any problems.
FreeBSD 3.3 however does have some problems.
*** ./expected/float8-small-is-zero.out Fri Mar 31 07:30:31 2000
--- ./results/float8.out Tue Mar 27 02:28:07 2001
***************
*** 214,220 **** SET f1 = FLOAT8_TBL.f1 * '-1' WHERE FLOAT8_TBL.f1 > '0.0'; SELECT '' AS bad, f.f1 * '1e200' from
FLOAT8_TBLf;
! ERROR: Bad float8 input format -- overflow SELECT '' AS bad, f.f1 ^ '1e200' from FLOAT8_TBL f; ERROR: pow() result
isout of range SELECT '' AS bad, ln(f.f1) from FLOAT8_TBL f where f.f1 = '0.0' ;
--- 214,220 ---- SET f1 = FLOAT8_TBL.f1 * '-1' WHERE FLOAT8_TBL.f1 > '0.0'; SELECT '' AS bad, f.f1 * '1e200' from
FLOAT8_TBLf;
! ERROR: floating point exception! The last floating point operation either exceeded legal ranges or was a divide by
zeroSELECT '' AS bad, f.f1 ^ '1e200' from FLOAT8_TBL f; ERROR: pow() result is out of range SELECT '' AS bad, ln(f.f1)
fromFLOAT8_TBL f where f.f1 = '0.0' ;
Some geometry tests also fail. I'll check those tomorrow, erm, today. The
same goes for 7.1RC1 on Solaris 8 (Intel and Sparc).
Cheers,
Mathijs
--
It's not that perl programmers are idiots, it's that the language
rewards idiotic behavior in a way that no other language or tool has
ever done. Erik Naggum
At 7:53 PM -0500 3/26/01, Tom Lane wrote: >Thomas Lockhart <lockhart@alumni.caltech.edu> writes: >>> "PPC750"? What's that? "PPC G3" might be more likely to mean something >>> to onlookers ... > >> Actually "G3" means nothing outside of Apple afaict. The 750 series is a >> follow-on to the 60x series, and there is a 7xxx series also. From my >> pov, using an accepted label, rather than a marketing (re)label, better >> indicates *what* this actually can run on. I'm not sure that I have it >> labeled correctly yet, but "G3" is not a step in the right direction. > >I found an apparently current "PowerPC CPU Summary" at >http://e-www.motorola.com/webapp/sps/technology/tech_tutorial.jsp?catId=M943030621280 > >If accurate, the chip in this PowerBook is *not* a 750, since that tops >out at 400 MHz. Apple offered this model in 400 and 500 MHz speeds, >which makes it either a 7400 or 7410 chip ... > >> Should I put "Mac G3" in the comment section? > >Yes, if you won't put it where it should be ;-). I'm still of the >opinion that "G3" will mean something to a vastly larger population >than "750" or "7400" would. The latter are "marketing relabels" too >you know; Motorola's internal designation would probably be something >else entirely. A "Me Too" from the peanut gallery. There are probably 1000x as many users that will recognize that they have a PowerPC G3 than will know they have a PPC750or PPC7400. -pmb
Re: Regression test on FBSD 3.3 & 4.2, IRIX 6.5 (was Re: Re: Call for platforms)
From
Tom Lane
Date:
Mathijs Brands <mathijs@ilse.nl> writes:
> Notice the single underscore before volatile.
That's definitely wrong --- fixed.
> Fixing this causes
> as (the SGI version, not GNU as) to choke on the '.global tas' statement.
> s_lock.c: At top level:
> s_lock.c:234: warning: `tas_dummy' defined but not used
> as: Error: /var/tmp/ccoUdrOb.s, line 421: undefined assembler operation: .global
> .global tas
> gmake[4]: *** [s_lock.o] Error 1
Perhaps it should be ".globl"? That's another common spelling.
Do you know whether anyone uses the GNU assembler on this platform,
or is it always SGI's? I'm wondering if we need two versions of the
assembly code ...
I had missed the fact that s_lock.c contains some MIPS code. Anyone
have any idea what versions of the MIPS series this code runs on?
regards, tom lane
Re: Regression test on FBSD 3.3 & 4.2, IRIX 6.5 (was Re: Re: Call for platforms)
From
Thomas Lockhart
Date:
> Do you know whether anyone uses the GNU assembler on this platform,
> or is it always SGI's? I'm wondering if we need two versions of the
> assembly code ...
Sure. Both compilers are available, with SGI's, uh, unique approach, and
with GNU's well understood assembler.
> I had missed the fact that s_lock.c contains some MIPS code. Anyone
> have any idea what versions of the MIPS series this code runs on?
There is a chance it is from the Ultrix days (very pre-1998 afaicr). Or
is it the *only* MIPS code in our tree? If so, then it probably supports
Tatsuo's dead Cobalt server box, which is fairly recent vintage.
- Thomas
On Mon, Mar 26, 2001 at 07:09:38PM -0500, Tom Lane wrote:
> Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
> > That is not already available from the Irix support code?
>
> What we have for IRIX is
> ...
> Doesn't look to me like it's likely to work on anything but IRIX ...
I have attached linuxthreads/sysdeps/mips/pt-machine.h from glibc-2.2.2
below. (Glibc linuxthreads has alpha, arm, hppa, i386, ia64, m68k, mips,
powerpc, s390, SH, and SPARC support, at least in some degree.)
Since the actual instruction sequence is probably lifted from the
MIPS manual, it's probably much freer than GPL. For the paranoid,
the actual instructions, extracted, are just
1: ll %0,%3 bnez %0,2f li %1,1 sc %1,%2 beqz %1,1b 2:
Nathan Myers
ncm@zembu.com
-----------------------------------
/* Machine-dependent pthreads configuration and inline functions.
Copyright (C) 1996, 1997, 1998, 2000 Free Software Foundation, Inc. This file is part of the GNU C Library.
Contributedby Ralf Baechle <ralf@gnu.org>. Based on the Alpha version by Richard Henderson <rth@tamu.edu>.
The GNU C Library is free software; you can redistribute it and/or modify it under the terms of the GNU Library
GeneralPublic License as published by the Free Software Foundation; either version 2 of the License, or (at your
option)any later version.
The GNU C Library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the
impliedwarranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Library General Public License
formore details.
You should have received a copy of the GNU Library General Public License along with the GNU C Library; see the file
COPYING.LIB. If not, write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307,
USA. */
#include <sgidefs.h>
#include <sys/tas.h>
#ifndef PT_EI
# define PT_EI extern inline
#endif
/* Memory barrier. */
#define MEMORY_BARRIER() __asm__ ("" : : : "memory")
/* Spinlock implementation; required. */
#if (_MIPS_ISA >= _MIPS_ISA_MIPS2)
PT_EI long int
testandset (int *spinlock)
{ long int ret, temp;
__asm__ __volatile__ ("/* Inline spinlock test & set */\n\t" "1:\n\t" "ll %0,%3\n\t" ".set push\n\t"
".set noreorder\n\t" "bnez %0,2f\n\t" " li %1,1\n\t" ".set pop\n\t" "sc %1,%2\n\t" "beqz
%1,1b\n" "2:\n\t" "/* End spinlock test & set */" : "=&r" (ret), "=&r" (temp), "=m" (*spinlock) : "m"
(*spinlock) : "memory");
return ret;
}
#else /* !(_MIPS_ISA >= _MIPS_ISA_MIPS2) */
PT_EI long int
testandset (int *spinlock)
{ return _test_and_set (spinlock, 1);
}
#endif /* !(_MIPS_ISA >= _MIPS_ISA_MIPS2) */
/* Get some notion of the current stack. Need not be exactly the top of the stack, just something somewhere in the
currentframe. */
#define CURRENT_STACK_FRAME stack_pointer
register char * stack_pointer __asm__ ("$29");
/* Compare-and-swap for semaphores. */
#if (_MIPS_ISA >= _MIPS_ISA_MIPS2)
#define HAS_COMPARE_AND_SWAP
PT_EI int
__compare_and_swap (long int *p, long int oldval, long int newval)
{ long int ret;
__asm__ __volatile__ ("/* Inline compare & swap */\n\t" "1:\n\t" "ll %0,%4\n\t" ".set push\n"
".set noreorder\n\t" "bne %0,%2,2f\n\t" " move %0,%3\n\t" ".set pop\n\t" "sc %0,%1\n\t"
"beqz %0,1b\n" "2:\n\t" "/* End compare & swap */" : "=&r" (ret), "=m" (*p) : "r" (oldval), "r" (newval),
"m"(*p) : "memory");
return ret;
}
#endif /* (_MIPS_ISA >= _MIPS_ISA_MIPS2) */
Thomas Lockhart <lockhart@alumni.caltech.edu> writes: > NetBSD Sparc 7.0 2000-04-13, Tom I. Helbekkmo Fetching the latest source kit now -- hope to have regression tests run and a report back to you within a day or two. > We need some NetBSD folks to speak up! I've once again got a VAX that should be able to run PostgreSQL on NetBSD/vax, so I hope to be able to help revitalize that port soon... -tih -- The basic difference is this: hackers build things, crackers break them.
ncm@zembu.com (Nathan Myers) writes: > Since the actual instruction sequence is probably lifted from the > MIPS manual, it's probably much freer than GPL. For the paranoid, > the actual instructions, extracted, are just > > 1: > ll %0,%3 > bnez %0,2f > li %1,1 > sc %1,%2 > beqz %1,1b > 2: But note that the ll instruction is MIPS ISA II, which means that it is not supported by the R3000, which means that it will not work on most DECstations. I don't think there is any way to do a reliable test-and-set sequence in user mode on an R3000. Ian
> mklinux PPC750 7.0 2000-04-13, Tatsuo Ishii > > Any luck with RC1? I will try today or tomorrow... -- Tatsuo Ishii
Thus spake Tom Ivar Helbekkmo
> > We need some NetBSD folks to speak up!
I have successfully compiled it from CVS sources on my NetBSD -current but
I can't find the tar file for RC1 to try it with the package system. Can
someone point me to it please.
--
D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
On Tue, Mar 27, 2001 at 06:36:37AM -0500, D'Arcy J.M. Cain allegedly wrote: > Thus spake Tom Ivar Helbekkmo > > > We need some NetBSD folks to speak up! > > I have successfully compiled it from CVS sources on my NetBSD -current but > I can't find the tar file for RC1 to try it with the package system. Can > someone point me to it please. It's probably in /pub/dev (or something similar) on the ftp server... Mathijs -- It's not that perl programmers are idiots, it's that the language rewards idiotic behavior in a way that no other language or tool has ever done. Erik Naggum
At 5:14 PM +0000 3/26/01, Thomas Lockhart wrote: >NetBSD m68k 7.0 2000-04-10, Henry B. Hotz I no longer have a 68k machine that's fast enough to reasonably test PG on. I have a IIcx that sometimes serves as a router, but I'm using some second-generation powermac's mostly now. (You still have that Centris in your closet Tom?) I *did* just get MacOS X this weekend though and if I get it working on my work G4 maybe I could give it a try there. Signature held pending an ISO 9000 compliant signature design and approval process. h.b.hotz@jpl.nasa.gov, or hbhotz@oxy.edu
-----BEGIN PGP SIGNED MESSAGE----- On 25 Mar 2001, at 16:07, Tom Lane wrote: > Does that database have any user-created relations in it, or is it > just a virgin database? It seems that the wrong attlen is being > computed for ctid fields during bootstrap, but the regression test > output (if it was complete) implies that the value inserted for > user-created fields was OK. This doesn't make a lot of sense since > it's the same code... Totally virgin. I created it just for that select you wanted. The 7.1beta6 I built was installed in /usr/pgsql so as to be entirely separate from any other running parts of the system. Like I said, the test failed, but it seems to *work* just fine... If you want the complete regress output, I'll send it as well. The only failures were the type_sanity and geometry though, and the geometry was just fluctuations on the final digit of a few numbers. I suspect it might be an alignment problem (ARM needs word or dword alignment on data access.. our kernel has an alignment trap handler that does fixups in 'broken' code) or something related to signedness (ARM has default signed char) but I don't know enough about postgres internals to really debug it. However, I'm certainly willing to learn.. :) -----BEGIN PGP SIGNATURE----- Version: N/A iQCVAwUBOsAFXf+IdJuhyV9xAQFpZgP8C7g9dqlh9Qd/wVwJn2jquVh+X3gBWBZ5 UMHx43tPfYE7xJvHl3XH/z+mg/POyzgFMCF+5USO2jzbPMDiS2OtJbp+1NvP2FHA uuY1ra5o8WKWW/7ZrfaO5edC5e1OsKbhGsXugRIyBwFkzz28blt6gongUdio0nC3 Td8Fm3GUKNk= =+//W -----END PGP SIGNATURE-----
One that didn't compilei RC1: BIGBOY 71# uname -a IRIX BIGBOY 6.5 05190003 IP22 On an Indigo2 (R4000), gcc 2.95.2 , with the following error: gcc -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../../src/include -U_NO_XOPEN4 -c s_lock.c -o s_lock.o s_lock.c: In function `s_lock': s_lock.c:134: warning: passing arg 1 of pointer to function discards qualifiers from pointer target type s_lock.c: In function `tas_dummy': s_lock.c:235: parse error before `_volatile__' s_lock.c: At top level: s_lock.c:234: warning: `tas_dummy' defined but not used gmake[4]: *** [s_lock.o] Error 1 gmake[4]: Leaving directory `/usr/people/telmnstr/pg/postgresql-7.1RC1/src/backend/storage/buffer' gmake[3]: *** [buffer-recursive] Error 2 gmake[3]: Leaving directory `/usr/people/telmnstr/pg/postgresql-7.1RC1/src/backend/storage' gmake[2]: *** [storage-recursive] Error 2 gmake[2]: Leaving directory `/usr/people/telmnstr/pg/postgresql-7.1RC1/src/backend' gmake[1]: *** [all] Error 2 gmake[1]: Leaving directory `/usr/people/telmnstr/pg/postgresql-7.1RC1/src' gmake: *** [all] Error 2 *** Error code 2 (bu21) Jeff
We just fixed that yesterday. Can you grab the most recent CVS and give it a try? > One that didn't compilei RC1: > > BIGBOY 71# uname -a > IRIX BIGBOY 6.5 05190003 IP22 > > On an Indigo2 (R4000), gcc 2.95.2 , with the following error: > > gcc -Wall -Wmissing-prototypes -Wmissing-declarations > -I../../../../src/include -U_NO_XOPEN4 -c s_lock.c -o s_lock.o > s_lock.c: In function `s_lock': > s_lock.c:134: warning: passing arg 1 of pointer to function discards > qualifiers from pointer target type > s_lock.c: In function `tas_dummy': > s_lock.c:235: parse error before `_volatile__' > s_lock.c: At top level: > s_lock.c:234: warning: `tas_dummy' defined but not used > gmake[4]: *** [s_lock.o] Error 1 > gmake[4]: Leaving directory > `/usr/people/telmnstr/pg/postgresql-7.1RC1/src/backend/storage/buffer' > gmake[3]: *** [buffer-recursive] Error 2 > gmake[3]: Leaving directory > `/usr/people/telmnstr/pg/postgresql-7.1RC1/src/backend/storage' > gmake[2]: *** [storage-recursive] Error 2 > gmake[2]: Leaving directory > `/usr/people/telmnstr/pg/postgresql-7.1RC1/src/backend' > gmake[1]: *** [all] Error 2 > gmake[1]: Leaving directory > `/usr/people/telmnstr/pg/postgresql-7.1RC1/src' > gmake: *** [all] Error 2 > *** Error code 2 (bu21) > > Jeff > > > > ---------------------------(end of broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org > -- 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
Jeff Duffy <jduffy@greatbridge.com> writes:
> s_lock.c:235: parse error before `_volatile__'
That typo is fixed in current sources (should be OK in last night's
snapshot) but there's still some doubt as to how well the MIPS assembly
code works ...
regards, tom lane
Re: Regression test on FBSD 3.3 & 4.2, IRIX 6.5 (was Re: Re: Call for platforms)
From
Peter Eisentraut
Date:
Mathijs Brands writes: > I just tried to compile 7.1RC1 on my IRIX 6.5 box using gcc 2.95.2. According to the information at http://freeware.sgi.com/shared/howto.html#b1 it probably won't work to compile PostgreSQL with GCC on Irix. Or it might work and crash when run. Be warned. (I think it is not accidental that no one ever successfully used a PostgreSQL/GCC/Irix combo.) -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
On Tue, Mar 27, 2001 at 09:57:45AM -0500, Bruce Momjian allegedly wrote: > We just fixed that yesterday. Can you grab the most recent CVS and give > it a try? Even if you fix this it won't work (I tried it). Robert mailed why. Check the URL below for more information. It crashes on semctl :( http://freeware.sgi.com/shared/howto.html#b1 Cheers, Mathijs -- It's not that perl programmers are idiots, it's that the language rewards idiotic behavior in a way that no other language or tool has ever done. Erik Naggum
I wrote: > > NetBSD Sparc 7.0 2000-04-13, Tom I. Helbekkmo > > Fetching the latest source kit now -- hope to have regression tests > run and a report back to you within a day or two. Hmm. No go here: everything looks peachy until I've started the postmaster, and attempt to connect to it: barsoom:postgres> psql template1 /usr/local/pgsql/lib/libpq.so.2: Undefined symbol "" (reloc type = 12, symnum = 4) barsoom:postgres> _ I've never seen this happen before... (For what it's worth, I use Kerberos IV authentication here, so that's what I've configured on this box as well. I notice that psql does not get as far as aquiring a service key for the database access.) Any quick hints? -tih -- The basic difference is this: hackers build things, crackers break them.
Mathijs Brands <mathijs@ilse.nl> writes: > Even if you fix this it won't work (I tried it). Robert mailed > why. Check the URL below for more information. It crashes on semctl :( > http://freeware.sgi.com/shared/howto.html#b1 Ugh. Given the semctl compatibility problem, I suspect we'd better note in the platform list that IRIX is only supported for cc, not gcc. The other uncomfy-looking thing on that page is the very first item, about configure scripts picking up libraries that they'd best not. (I have seen similar issues on HPUX, although they were relatively easy to get around.) We might need to do some more hacking on our configure script to make it play nice on IRIX. regards, tom lane
Tom Ivar Helbekkmo <tih@kpnqwest.no> wrote: > Thomas Lockhart <lockhart@alumni.caltech.edu> writes: >> NetBSD Sparc 7.0 2000-04-13, Tom I. Helbekkmo > Fetching the latest source kit now -- hope to have regression tests > run and a report back to you within a day or two. >> We need some NetBSD folks to speak up! > I've once again got a VAX that should be able to run PostgreSQL on > NetBSD/vax, so I hope to be able to help revitalize that port soon... it might also be a good idea to ask on the NetBSD ports lists - i think there will most probably some people trying things out - the name of the list is port-arch@NetBSD.org where arch is the corresponding NetBSD port name (pmax, macppc, sparc, i386, arm32, ...) this might also be a good idea for the mips test-and-set thing (on the port-pmax list - there are a lot of people knowing all that stuff very well) also it might be worth to eventually ask on the alpha@FreeBSD.org list for someone willing to play with PostgreSQL on FreeBSD/alpha just some ideas ... t -- thomas graichen <tgr@spoiled.org> ... perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away. --- antoine de saint-exupery
> > mklinux PPC750 7.0 2000-04-13, Tatsuo Ishii > > > > Any luck with RC1? > > I will try today or tomorrow... In summary no, improvemnets seen. If compiled with -O2 or -O2 -g, I got 10 tests FAILED. misc test failed due to a backend crash. The SQL caused the crash was: select i, length(t), octet_length(t), oldstyle_length(i,t) from oldstyle_test; #0 ExecReplace (slot=0x1a4a7d0, tupleid=0x0, estate=0x1a4a708) at execMain.c:1408 1408 resultRelationDesc = resultRelInfo->ri_RelationDesc; (gdb) where #0 ExecReplace (slot=0x1a4a7d0, tupleid=0x0, estate=0x1a4a708) at execMain.c:1408 #1 0x188471c in ExecutePlan (estate=0x0, plan=0x1a4a410, operation=CMD_SELECT, numberTuples=0, direction=27567836, destfunc=0x1a4adf8) at execMain.c:1127 #2 0x188471c in ExecutePlan (estate=0x0, plan=0x1a4a410, operation=CMD_SELECT, numberTuples=0, direction=27567836, destfunc=0x1a4adf8) at execMain.c:1127 #3 0x18838b8 in ExecutorRun (queryDesc=0x1a4a7d0, estate=0x1a4a708, feature=27567784, count=0) at execMain.c:233 #4 0x18e7784 in ProcessQuery (parsetree=0x1a4a708, plan=0x1a4a6a8, dest=None) at pquery.c:295 #5 0x18e5c38 in pg_exec_query_string (query_string=0x1a4a410 "", dest=None, parse_context=0x1) at postgres.c:806 #6 0x18e70b8 in PostgresMain (argc=1, argv=0x0, real_argc=4, real_argv=0x0, username=0x0) at postgres.c:1902 #7 0x18c92ec in DoBackend (port=0x1a4a6a8) at postmaster.c:2111 #8 0x18c8e10 in BackendStartup (port=0x1a4a708) at postmaster.c:1894 #9 0x18c7c08 in ServerLoop () at postmaster.c:992 #10 0x18c74f4 in PostmasterMain (argc=0, argv=0x1a4a6a8) at postmaster.c:682 #11 0x1899a5c in main (argc=27567784, argv=0x1a4a708) at main.c:147 #12 0x181c400 in _start () (gdb)
Tatsuo Ishii <t-ishii@sra.co.jp> writes:
> > mklinux PPC750 7.0 2000-04-13, Tatsuo Ishii
> If compiled with -O2 or -O2 -g, I got 10 tests FAILED. misc test
> failed due to a backend crash. The SQL caused the crash was:
> select i, length(t), octet_length(t), oldstyle_length(i,t) from
> oldstyle_test;
> #0 ExecReplace (slot=0x1a4a7d0, tupleid=0x0, estate=0x1a4a708)
> at execMain.c:1408
> 1408 resultRelationDesc = resultRelInfo->ri_RelationDesc;
> (gdb) where
> #0 ExecReplace (slot=0x1a4a7d0, tupleid=0x0, estate=0x1a4a708)
> at execMain.c:1408
> #1 0x188471c in ExecutePlan (estate=0x0, plan=0x1a4a410,
> operation=CMD_SELECT, numberTuples=0, direction=27567836,
> destfunc=0x1a4adf8) at execMain.c:1127
> #2 0x188471c in ExecutePlan (estate=0x0, plan=0x1a4a410,
> operation=CMD_SELECT, numberTuples=0, direction=27567836,
> destfunc=0x1a4adf8) at execMain.c:1127
> #3 0x18838b8 in ExecutorRun (queryDesc=0x1a4a7d0, estate=0x1a4a708,
> feature=27567784, count=0) at execMain.c:233
I think you've got a badly broken compiler there. There's no way that
ExecReplace should be entered for a SELECT. The backtrace is wrong on
its face anyway --- ExecutePlan does not call itself.
What gcc version does that platform have?
regards, tom lane
> I think you've got a badly broken compiler there. There's no way that > ExecReplace should be entered for a SELECT. The backtrace is wrong on > its face anyway --- ExecutePlan does not call itself. Yes, I have suspected that. > What gcc version does that platform have? gcc version egcs-2.90.25 980302 (egcs-1.0.2 prerelease) -- Tatsuo Ishii
Tatsuo Ishii <t-ishii@sra.co.jp> writes:
>> What gcc version does that platform have?
> gcc version egcs-2.90.25 980302 (egcs-1.0.2 prerelease)
Can you try a known-stable gcc version? 2.95.2 say?
regards, tom lane
> Tatsuo Ishii <t-ishii@sra.co.jp> writes: > >> What gcc version does that platform have? > > > gcc version egcs-2.90.25 980302 (egcs-1.0.2 prerelease) > > Can you try a known-stable gcc version? 2.95.2 say? I don't have time right know. Will do maybe for 7.1.1 or 7.2.. -- Tatsuo Ishii
On Tue, 27 Mar 2001 09:57:45 -0500 (EST), Bruce Momjian alluded: > > We just fixed that yesterday. Can you grab the most recent CVS and give > it a try? Yep. We have many other MIPS (ONYX Crimson, , ONYX, Challenge, Indy w/ IRIX 6.2, 6.5, etc.), Alpha and Sparc platforms if there are some others that need testing (How about NetBSD on NeXT?). Jeff -- Jeff Duffyjeff@alanne.com
> Yep. We have many other MIPS (ONYX Crimson, , ONYX, Challenge, Indy w/ IRIX
> 6.2, 6.5, etc.), Alpha and Sparc platforms if there are some others that need
> testing (How about NetBSD on NeXT?).
All of these are interesting to help others decide whether their
particular machine is supported. For my narrow purposes of documenting
which kinds of platforms are supported for the upcoming release, I'm
focused on processor/OS combinations. So the following already seem to
be covered:
MIPS/IRIX (32 bit compilation only- try 64 bit compilation?)
Alpha/Linux
Alpha/Tru64
Sparc/Solaris
Sparc/Linux
x86/NetBSD (need all other NetBSD architectures!)
x86/OpenBSD (need all other archs!)
If you have other combinations (I've forgotten what NeXT is; we need 68k
and 88k architectures tested; our NetBSD/68k guy no longer has that
machine) they would be particularly helpful.
TIA
- Thomas
Tom Ivar Helbekkmo <tih@kpnQwest.no> writes:
> > We need some NetBSD folks to speak up!
>
> I've once again got a VAX that should be able to run PostgreSQL on
> NetBSD/vax, so I hope to be able to help revitalize that port soon...
It still works. RC1 configures, compiles and runs on my VAX 4000/500
with NetBSD-current -- but the regression tests give a lot of failures
because the VAX doesn't have IEEE math, leading to different rounding
and erroneous assumptions about the limits of floating point values.
I'll be looking at this more closely.
Also, dynamic loading now works on NetBSD/vax, so my old #ifdef for
that in the backend/port/bsd.c file, which has since propagated into
the new *bsd.c files, can go away (actually, I'm suspicious of the
MIPS part of those, too, but I didn't put that in, and I don't have
any MIPS-based machines):
Index: src/backend/port/dynloader/freebsd.c
===================================================================
RCS file: /home/projects/pgsql/cvsroot/pgsql/src/backend/port/dynloader/freebsd.c,v
retrieving revision 1.9
diff -c -r1.9 freebsd.c
*** src/backend/port/dynloader/freebsd.c 2001/02/10 02:31:26 1.9
--- src/backend/port/dynloader/freebsd.c 2001/04/01 08:01:20
***************
*** 63,69 **** void * BSD44_derived_dlopen(const char *file, int num) {
! #if defined(__mips__) || (defined(__NetBSD__) && defined(__vax__)) sprintf(error_message, "dlopen (%s) not
supported",file); return NULL; #else
--- 63,69 ---- void * BSD44_derived_dlopen(const char *file, int num) {
! #if defined(__mips__) sprintf(error_message, "dlopen (%s) not supported", file); return NULL; #else
***************
*** 78,84 **** void * BSD44_derived_dlsym(void *handle, const char *name) {
! #if defined(__mips__) || (defined(__NetBSD__) && defined(__vax__)) sprintf(error_message, "dlsym (%s) failed",
name); return NULL; #else
--- 78,84 ---- void * BSD44_derived_dlsym(void *handle, const char *name) {
! #if defined(__mips__) sprintf(error_message, "dlsym (%s) failed", name); return NULL; #else
***************
*** 101,107 **** void BSD44_derived_dlclose(void *handle) {
! #if defined(__mips__) || (defined(__NetBSD__) && defined(__vax__)) #else dlclose(handle); #endif
--- 101,107 ---- void BSD44_derived_dlclose(void *handle) {
! #if defined(__mips__) #else dlclose(handle); #endif
Index: src/backend/port/dynloader/netbsd.c
===================================================================
RCS file: /home/projects/pgsql/cvsroot/pgsql/src/backend/port/dynloader/netbsd.c,v
retrieving revision 1.3
diff -c -r1.3 netbsd.c
*** src/backend/port/dynloader/netbsd.c 2001/02/10 02:31:26 1.3
--- src/backend/port/dynloader/netbsd.c 2001/04/01 08:01:20
***************
*** 63,69 **** void * BSD44_derived_dlopen(const char *file, int num) {
! #if defined(__mips__) || (defined(__NetBSD__) && defined(__vax__)) sprintf(error_message, "dlopen (%s) not
supported",file); return NULL; #else
--- 63,69 ---- void * BSD44_derived_dlopen(const char *file, int num) {
! #if defined(__mips__) sprintf(error_message, "dlopen (%s) not supported", file); return NULL; #else
***************
*** 78,84 **** void * BSD44_derived_dlsym(void *handle, const char *name) {
! #if defined(__mips__) || (defined(__NetBSD__) && defined(__vax__)) sprintf(error_message, "dlsym (%s) failed",
name); return NULL; #elif defined(__ELF__)
--- 78,84 ---- void * BSD44_derived_dlsym(void *handle, const char *name) {
! #if defined(__mips__) sprintf(error_message, "dlsym (%s) failed", name); return NULL; #elif defined(__ELF__)
***************
*** 101,107 **** void BSD44_derived_dlclose(void *handle) {
! #if defined(__mips__) || (defined(__NetBSD__) && defined(__vax__)) #else dlclose(handle); #endif
--- 101,107 ---- void BSD44_derived_dlclose(void *handle) {
! #if defined(__mips__) #else dlclose(handle); #endif
Index: src/backend/port/dynloader/openbsd.c
===================================================================
RCS file: /home/projects/pgsql/cvsroot/pgsql/src/backend/port/dynloader/openbsd.c,v
retrieving revision 1.3
diff -c -r1.3 openbsd.c
*** src/backend/port/dynloader/openbsd.c 2001/02/10 02:31:26 1.3
--- src/backend/port/dynloader/openbsd.c 2001/04/01 08:01:20
***************
*** 63,69 **** void * BSD44_derived_dlopen(const char *file, int num) {
! #if defined(__mips__) || (defined(__NetBSD__) && defined(__vax__)) sprintf(error_message, "dlopen (%s) not
supported",file); return NULL; #else
--- 63,69 ---- void * BSD44_derived_dlopen(const char *file, int num) {
! #if defined(__mips__) sprintf(error_message, "dlopen (%s) not supported", file); return NULL; #else
***************
*** 78,84 **** void * BSD44_derived_dlsym(void *handle, const char *name) {
! #if defined(__mips__) || (defined(__NetBSD__) && defined(__vax__)) sprintf(error_message, "dlsym (%s) failed",
name); return NULL; #elif defined(__ELF__)
--- 78,84 ---- void * BSD44_derived_dlsym(void *handle, const char *name) {
! #if defined(__mips__) sprintf(error_message, "dlsym (%s) failed", name); return NULL; #elif defined(__ELF__)
***************
*** 101,107 **** void BSD44_derived_dlclose(void *handle) {
! #if defined(__mips__) || (defined(__NetBSD__) && defined(__vax__)) #else dlclose(handle); #endif
--- 101,107 ---- void BSD44_derived_dlclose(void *handle) {
! #if defined(__mips__) #else dlclose(handle); #endif
-tih
--
The basic difference is this: hackers build things, crackers break them.
Tom Ivar Helbekkmo <tih@kpnQwest.no> writes:
> Also, dynamic loading now works on NetBSD/vax, so my old #ifdef for
> that in the backend/port/bsd.c file, which has since propagated into
> the new *bsd.c files, can go away.
Patch applied, thanks.
regards, tom lane
> > I've once again got a VAX that should be able to run PostgreSQL on
> > NetBSD/vax, so I hope to be able to help revitalize that port soon...
> It still works. RC1 configures, compiles and runs on my VAX 4000/500
> with NetBSD-current -- but the regression tests give a lot of failures
> because the VAX doesn't have IEEE math, leading to different rounding
> and erroneous assumptions about the limits of floating point values.
> I'll be looking at this more closely.
Great! Will put it on the list :)
- Thomas
Did we decide that "most NetBSD/i386 users have fpus" in which case Marko's patch should be applied? Cheers, Patrick (just checked, it isn't in today's cvs) On Thu, Mar 22, 2001 at 10:27:44PM +0200, Marko Kreen wrote: > On Thu, Mar 22, 2001 at 07:58:04PM +0000, Patrick Welche wrote: > > On Fri, Mar 23, 2001 at 06:25:50AM +1100, Giles Lean wrote: > > > > > > > PS: AFAIK geometry-positive-zeros-bsd works for all NetBSD platforms - the > > > > above difference is only for i386 + fpu. > > > > > > It doesn't on NetBSD-1.5/alpha -- there geometry-positive-zeros is > > > correct. > > > > Sorry, that should have read: > > > > AFAIK geometry-positive-zeros works for all NetBSD platforms - the > > above difference is only for i386 + fpu. > > Seems that following patch is needed. Now It Works For Me (tm). > Giles, does the regress test now succed for you? > > -- > marko > > > Index: src/test/regress/resultmap > =================================================================== > RCS file: /home/projects/pgsql/cvsroot/pgsql/src/test/regress/resultmap,v > retrieving revision 1.45 > diff -u -r1.45 resultmap > --- src/test/regress/resultmap 2001/03/22 15:13:18 1.45 > +++ src/test/regress/resultmap 2001/03/22 17:29:49 > @@ -17,6 +17,7 @@ > geometry/.*-openbsd=geometry-positive-zeros-bsd > geometry/.*-irix6=geometry-irix > geometry/.*-netbsd=geometry-positive-zeros > +geometry/i.86-.*-netbsdelf1.5=geometry-positive-zeros-bsd > geometry/.*-sysv5uw7.*:cc=geometry-uw7-cc > geometry/.*-sysv5uw7.*:gcc=geometry-uw7-gcc > geometry/alpha.*-dec-osf=geometry-alpha-precision > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster
> Did we decide that "most NetBSD/i386 users have fpus" in which case Marko's
> patch should be applied?
I'm unclear on what y'all mean by "i386 + fpu", especially since NetBSD
seems to insist on calling every Intel processor a "i386". In this case,
are you suggesting that this patch covers all NetBSD installations on
every Intel processor from i386 + fpu forward to i486, i586, etc etc? Or
is this specifically for the i386 with the 80387 coprocessor which is
how any reasonable person would interpret "i386+fpu"? ;)
- Thomas
> > Index: src/test/regress/resultmap
> > ===================================================================
> > RCS file: /home/projects/pgsql/cvsroot/pgsql/src/test/regress/resultmap,v
> > retrieving revision 1.45
> > diff -u -r1.45 resultmap
> > --- src/test/regress/resultmap 2001/03/22 15:13:18 1.45
> > +++ src/test/regress/resultmap 2001/03/22 17:29:49
> > @@ -17,6 +17,7 @@
> > geometry/.*-openbsd=geometry-positive-zeros-bsd
> > geometry/.*-irix6=geometry-irix
> > geometry/.*-netbsd=geometry-positive-zeros
> > +geometry/i.86-.*-netbsdelf1.5=geometry-positive-zeros-bsd
> > geometry/.*-sysv5uw7.*:cc=geometry-uw7-cc
> > geometry/.*-sysv5uw7.*:gcc=geometry-uw7-gcc
> > geometry/alpha.*-dec-osf=geometry-alpha-precision
On Fri, Apr 13, 2001 at 01:25:45PM +0000, Thomas Lockhart wrote: > > Did we decide that "most NetBSD/i386 users have fpus" in which case Marko's > > patch should be applied? > > I'm unclear on what y'all mean by "i386 + fpu", especially since NetBSD > seems to insist on calling every Intel processor a "i386". History ;-) > In this case, > are you suggesting that this patch covers all NetBSD installations on > every Intel processor from i386 + fpu forward to i486, i586, etc etc? Yes! It's simply, if the peecee type thing has a fpu (as in the sysctl machdep.fpu_present returns 1), then libm387.so is used, and you get differences in the (from memory 44th insignificant figure?) otherwise it just uses libm.so and you get what is currently correct in resultmap. Cheers, Patrick