Call for platforms

* 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

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

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

Gilles DAROLD wrote:

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

But when I configure with --with-perl I have the following error :

Ok symbolic link between cc and gcc seem to be the better fix.

I have now tested the --with-CXX option to compile libpq++ and it
really don't work, here are the output :

ld: 0711-319 WARNING: Exported symbol not defined:
PgConnection::CloseConnection
ld: 0711-319 WARNING: Exported symbol not defined: PgConnection::Connect
ld: 0711-319 WARNING: Exported symbol not defined: PgConnection::ConnectionBad

ld: 0711-319 WARNING: Exported symbol not defined: PgConnection::DBName
ld: 0711-319 WARNING: Exported symbol not defined: PgConnection::ErrorMessage
ld: 0711-319 WARNING: Exported symbol not defined: PgConnection::Exec
ld: 0711-319 WARNING: Exported symbol not defined: PgConnection::ExecCommandOk

ld: 0711-319 WARNING: Exported symbol not defined: PgConnection::ExecTuplesOk
ld: 0711-319 WARNING: Exported symbol not defined: PgConnection::IntToString

....

ld: 0711-317 ERROR: Undefined symbol: basic_string<char,
string_char_traits<char>, __default_alloc_template<false, 0> >::nilRep
ld: 0711-317 ERROR: Undefined symbol:
__malloc_alloc_template<0>::__malloc_alloc_oom_handler
ld: 0711-317 ERROR: Undefined symbol: endl(ostream &)
ld: 0711-317 ERROR: Undefined symbol: cerr
ld: 0711-317 ERROR: Undefined symbol: .ostream::operator<<(char const *)
ld: 0711-317 ERROR: Undefined symbol: __default_alloc_template<false,
0>::_S_end_free
ld: 0711-317 ERROR: Undefined symbol: __default_alloc_template<false,
0>::_S_start_free
ld: 0711-317 ERROR: Undefined symbol: __default_alloc_template<false,
0>::_S_heap_size
ld: 0711-317 ERROR: Undefined symbol: __default_alloc_template<false,
0>::_S_free_list
ld: 0711-317 ERROR: Undefined symbol: .__out_of_range(char const *)
ld: 0711-317 ERROR: Undefined symbol: .__length_error(char const *)
collect2: ld returned 8 exit status
make[3]: *** [libpq++.so] Error 1
make[3]: Leaving directory
`/home/darold/postgresql-7.1beta6/src/interfaces/libpq++'
make[2]: *** [all] Error 2

I have change the Makefile.global and replace c++ by g++ but it the same
output.

Could you tell me what going wrong ? Is my GNU install not fully functionnal ?

I use :
gcc version 2.95.2.1 19991024 (release) libs for powerpc-ibm-aix4.3.2.0

Regards

Gilles DAROLD

Gilles DAROLD writes:

I have now tested the --with-CXX option to compile libpq++ and it
really don't work, here are the output :

ld: 0711-317 ERROR: Undefined symbol: __default_alloc_template<false,
0>::_S_start_free
ld: 0711-317 ERROR: Undefined symbol: __default_alloc_template<false,
0>::_S_heap_size
ld: 0711-317 ERROR: Undefined symbol: __default_alloc_template<false,
0>::_S_free_list
ld: 0711-317 ERROR: Undefined symbol: .__out_of_range(char const *)
ld: 0711-317 ERROR: Undefined symbol: .__length_error(char const *)
collect2: ld returned 8 exit status
make[3]: *** [libpq++.so] Error 1
make[3]: Leaving directory
`/home/darold/postgresql-7.1beta6/src/interfaces/libpq++'
make[2]: *** [all] Error 2

This could be a name mangling problem. Maybe the linker needs to be
invoked specially when building C++ libraries. Maybe the C++ compiler
driver needs to be invoked directly. This could especially be a problem
if you're using the GNU compiler with system libraries, since those are
usually compiled by the system compiler.

I have change the Makefile.global and replace c++ by g++ but it the same
output.

I think the good C++ compiler on AIX is called xlC. In any case, make
sure that you don't mix different C++ compilers. You need to do 'gmake
clean' at least in the libpq++ directory if you're switching.

--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/

Peter Eisentraut wrote:

This could be a name mangling problem. Maybe the linker needs to be
invoked specially when building C++ libraries. Maybe the C++ compiler
driver needs to be invoked directly. This could especially be a problem
if you're using the GNU compiler with system libraries, since those are
usually compiled by the system compiler.

I have change the Makefile.global and replace c++ by g++ but it the same
output.

I think the good C++ compiler on AIX is called xlC. In any case, make
sure that you don't mix different C++ compilers. You need to do 'gmake
clean' at least in the libpq++ directory if you're switching.

AIX faq said that xlC compiler don't work with libpq++ but with g++ it
may works :

libpq++ does not work because xlC does not have the string and bool

classes.

compiling the few files, that fail, with g++ does work.

Humm, I have no xlC compiler installed.Here are the compilation lines :

make[3]: Entering directory
`/home/darold/postgresql-7.1beta6/src/interfaces/libpq++'
g++ -O2 -Wall -I../../../src/interfaces/libpq -I../../../src/include
-I/usr/local/include -c -o pgconnection.o p
gconnection.cc
g++ -O2 -Wall -I../../../src/interfaces/libpq -I../../../src/include
-I/usr/local/include -c -o pgdatabase.o pgd
atabase.cc
g++ -O2 -Wall -I../../../src/interfaces/libpq -I../../../src/include
-I/usr/local/include -c -o pgtransdb.o pgtr
ansdb.cc
g++ -O2 -Wall -I../../../src/interfaces/libpq -I../../../src/include
-I/usr/local/include -c -o pgcursordb.o pgc
ursordb.cc
g++ -O2 -Wall -I../../../src/interfaces/libpq -I../../../src/include
-I/usr/local/include -c -o pglobject.o pglo
bject.cc
ar crs libpq++.a pgconnection.o pgdatabase.o pgtransdb.o pgcursordb.o
pglobject.o
touch libpq++.a
../../../src/backend/port/aix/mkldexport.sh libpq++.a > libpq++.exp
/usr/local/bin/gcc -Wl,-H512 -Wl,-bM:SRE
-Wl,-bI:../../../src/backend/postgres.imp -Wl,-bE:libpq++.exp -o libpq++.
so libpq++.a -L/usr/local/lib -L../../../src/interfaces/libpq -lpq -lc
ld: 0711-224 WARNING: Duplicate symbol: __start

All work until it want to link with libraries, it seems to want the libc
(-lc) and I don't
have it installed. Is it normal or this realease is not portable with AIX
4.3.3 ?

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:

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

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:

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

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

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?

So more-or-less the *same* configuration as is required for FBSD? If so,
I could note that in the comments part of the platform support table.

I'm not sure if either one (OBSD, FBSD) is actually explicitly
documented for PostgreSQL (I don't see a FAQ, and am not sure if there
is something in the sgml docs). Does anyone know if and where these
things are noted?

- Thomas

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

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?

So more-or-less the *same* configuration as is required for FBSD? If so,
I could note that in the comments part of the platform support table.

The kernel changes are the same, but OBSD needs the max proc, max open
file settings changes (no reboot required).

I'm not sure if either one (OBSD, FBSD) is actually explicitly
documented for PostgreSQL (I don't see a FAQ, and am not sure if there
is something in the sgml docs). Does anyone know if and where these
things are noted?

http://www.postgresql.org/devel-corner/docs/postgres/kernel-resources.html

This is the closest thing to docs. kernel-resources for specific OSs.

- b

b. palmer, bpalmer@crimelabs.net
pgp: www.crimelabs.net/bpalmer.pgp5

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/

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/

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/

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:

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?

So more-or-less the *same* configuration as is required for FBSD? If so,
I could note that in the comments part of the platform support table.

Quite a few platforms will need some tuning in that area before production
use. This is all documented.

I'm not sure if either one (OBSD, FBSD) is actually explicitly
documented for PostgreSQL (I don't see a FAQ, and am not sure if there
is something in the sgml docs). Does anyone know if and where these
things are noted?

- Thomas

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

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

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

NetBSD 2.8 alpha 7.1 2001-03-22, Giles Lean

Correction: NetBSD-1.5/alpha.

Ciao,

Giles

NetBSD 2.8 alpha 7.1 2001-03-22, Giles Lean

Correction: NetBSD-1.5/alpha.

Right. That was a typo in transcribing my online copy of the sgml docs
to the email. I was hoping no one caught it, and didn't bother sending a
correction ;)

- Thomas

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

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

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

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

Seems that following patch is needed. Now It Works For Me (tm).
Giles, does the regress test now succed for you?

Yes, but I don't like that it is 1.5 specific. I expect that later
NetBSD/i386 releases will also have the "new" floating point behaviour
by default, subject to /etc/ld.so.conf setting as Patrick Welche
discovered.

BTW NetBSD just uses "i386" for any x86. It's not necessary to allow
for i486, i586 etc.

Perhaps the resultmap format could be enhanced to allow wildcarding of
the result files, and just accept either match?

geometry/.*-netbsd=geometry-positive-zeros*

Regards,

Giles

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.

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

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 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 at Pop4 Networking
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================

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

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:

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

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:

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

======================================================================

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

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

"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

-----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 query
You are currently connected 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-----

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

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:

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

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

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

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:

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

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

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.

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 at Pop4 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

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

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

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:

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

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."
Umberto Eco

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

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

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_TBL f;
! ERROR:  Bad float8 input format -- overflow
  SELECT '' AS bad, f.f1 ^ '1e200' from FLOAT8_TBL f;
  ERROR:  pow() result is out 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_TBL f;
! ERROR:  floating point exception! The last floating point operation either exceeded legal ranges or was a divide by zero
  SELECT '' AS bad, f.f1 ^ '1e200' from FLOAT8_TBL f;
  ERROR:  pow() result is out of range
  SELECT '' AS bad, ln(f.f1) from FLOAT8_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

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

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 PPC750 or PPC7400.

-pmb

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

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.
Contributed by 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 General Public 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 implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
Library General Public License for more 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 current frame. */
#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) */

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:

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:

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.

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

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

"Mark Knox" <segfault@hardline.org> writes:

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?

Totally virgin. I created it just for that select you wanted.

Okay. Would you create a couple of random tables in it and do the
select again? I want to see what ctid looks like in a user-created
table.

I suspect it might be an alignment problem

Sort of. I am suspicious that sizeof(ItemPointerData) is returning 8
rather than 6 as one might expect.

regards, tom lane

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

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, Pennsylvania 19026

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

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, 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 Duffy
jeff@alanne.com

I've already reported this to the webpage, but I got a fail on the random
test:

random ... failed (ignored)

This is on a stock RedHat 7.0 kernel box with the SMP kernel (but running a
single processor):

[pjm3@localhost regress]$ less regression.diffs
*** ./expected/random.out       Thu Jan  6 06:40:54 2000
--- ./results/random.out        Tue Mar 27 15:07:16 2001
***************
*** 25,31 ****
    GROUP BY random HAVING count(random) > 1;
   random | count
  --------+-------
! (0 rows)

  SELECT random FROM RANDOM_TBL
    WHERE random NOT BETWEEN 80 AND 120;
--- 25,32 ----
    GROUP BY random HAVING count(random) > 1;
   random | count
  --------+-------
!      99 |     2
! (1 row)

SELECT random FROM RANDOM_TBL
WHERE random NOT BETWEEN 80 AND 120;

======================================================================

Regards,
Phil

+----------------------------------+
| Phil Mayers, Network Support |
| Centre for Computing Services |
| Imperial College |
+----------------------------------+

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

"Mayers, Philip J" <p.mayers@ic.ac.uk> writes:

I've already reported this to the webpage, but I got a fail on the random
test:
random ... failed (ignored)

See
http://www.postgresql.org/devel-corner/docs/postgres/regress.html
especially the last item ...

regards, tom lane

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)

-----BEGIN PGP SIGNED MESSAGE-----

On 26 Mar 2001, at 23:14, Tom Lane wrote:

"Mark Knox" <segfault@hardline.org> writes:

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?

Totally virgin. I created it just for that select you wanted.

Okay. Would you create a couple of random tables in it and do the
select again? I want to see what ctid looks like in a user-created
table.

Sure. I created two tables called 'test1' and 'test2'. Test1 has a
single field 'field1' of type int4. Test2 has two fields 'field1' and
'field2' of types char(200) and int4 respectively.

Here are the results:

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
18724| 18721|test1 |ctid | 8|i |f
18735| 18731|test2 |ctid | 8|i |f
(39 rows)

I suspect it might be an alignment problem

Sort of. I am suspicious that sizeof(ItemPointerData) is returning 8
rather than 6 as one might expect.

Maybe it's padding the structure to a dword boundary? ARM is
notorious for such things.. I will rebuild it with
__attribute__((packed)) on the struct and see if the size changes..

-----BEGIN PGP SIGNATURE-----
Version: N/A

iQCVAwUBOsFDJP+IdJuhyV9xAQEKxQP/YJXTxZppLd7ECk4BSwDZaStP4+bE6acc
StT//i/drdPC53DDWqiXLGA0bS384EXxyjvvaO1bTXzVFU/3+X/pY6YN/G3HMoah
dbCXRli2Y57yansf1WaVmK1lhiAqLy3iGYFp2nZvO1Sl1u+ba89HtV+G+iaKZSTr
U+HWTU3nnOM=
=vkY+
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----

On 27 Mar 2001, at 20:49, Mark Knox wrote:

I suspect it might be an alignment problem

Sort of. I am suspicious that sizeof(ItemPointerData) is returning
8 rather than 6 as one might expect.

Maybe it's padding the structure to a dword boundary? ARM is
notorious for such things.. I will rebuild it with
__attribute__((packed)) on the struct and see if the size changes..

Aha, progress! The packed directive gives attlen of 6 across the
board! Type_sanity test passes now too, so the only failing
regression test is geometry and that is easily dismissed. The
variation is in the last decimal place and probably due to emulated
floating point (ARM has no FPU).

The patch is attached.. it's tiny but seems to be effective.

-----BEGIN PGP SIGNATURE-----
Version: N/A

iQCVAwUBOsFeUv+IdJuhyV9xAQE2XAP9FF93ew+6Ml5iZ1jWjcGrs+3zaXIeWef6
SytNtIfyJqmcnyWnMaxBTlChIvBO5A2HVnBkCydM5BjUXdW1eWsEynrd+U79Yc+e
yVDGo30CK3lAkTLH3Fo6jR3YZe/TsIyr80WlDeqJiWvDmHTfqvo50jRiDq2h1OL/
LmI4YIQM0rQ=
=Vwwp
-----END PGP SIGNATURE-----

The following section of this message contains a file attachment
prepared for transmission using the Internet MIME message format.
If you are using Pegasus Mail, or any another MIME-compliant system,
you should be able to save it or view it from within your mailer.
If you cannot, please ask your system administrator for assistance.

---- File information -----------
File: arm-alignment.patch
Date: 27 Mar 2001, 21:26
Size: 533 bytes.
Type: Unknown

"Mark Knox" <segfault@hardline.org> writes:

{
BlockIdData ip_blkid;
OffsetNumber ip_posid;
+#ifdef __arm__
+} __attribute__((packed)) ItemPointerData;
+#else
}
+#endif

That would fix it for ARM but not for anyplace else with similar
alignment behavior. Would you try this patch instead to see what
happens?

regards, tom lane

*** src/backend/catalog/heap.c.orig	Thu Mar 22 09:50:36 2001
--- src/backend/catalog/heap.c	Wed Mar 28 00:24:45 2001
***************
*** 103,109 ****
   */

static FormData_pg_attribute a1 = {
! 0xffffffff, {"ctid"}, TIDOID, 0, sizeof(ItemPointerData),
SelfItemPointerAttributeNumber, 0, -1, -1, '\0', 'p', '\0', 'i', '\0', '\0'
};

--- 103,109 ----
   */

static FormData_pg_attribute a1 = {
! 0xffffffff, {"ctid"}, TIDOID, 0, SizeOfIptrData,
SelfItemPointerAttributeNumber, 0, -1, -1, '\0', 'p', '\0', 'i', '\0', '\0'
};

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

At 12:27 AM 3/28/01 -0500, Tom Lane wrote:

That would fix it for ARM but not for anyplace else with similar
alignment behavior. Would you try this patch instead to see what
happens?

I don't think this solution would be valid on many other platforms. It forces the structure to not be padded, and assumes that the cpu will be able to fetch from unaligned boundaries. The only reason this works is that the arm linux kernel contains an alignment trap handler that catches the fault and does a fixup on the access. Otherwise it would crash with SIGBUS.

static FormData_pg_attribute a1 = {
! 0xffffffff, {"ctid"}, TIDOID, 0, SizeOfIptrData,
SelfItemPointerAttributeNumber, 0, -1, -1, '\0', 'p', '\0', 'i', '\0', '\0'
};

Well, this patch seems to produce attlens of 6 as desired, but it causes many (13) of the regression tests to fail. Do you want to see the regression.diffs?

Mark Knox <segfault@hardline.org> writes:

I don't think this solution would be valid on many other platforms.

Au contraire --- the ARM is the first platform I've heard of that does
not think sizeof(ItemPointerData) is 6. Else we'd have seen this
regress test fail before.

Well, this patch seems to produce attlens of 6 as desired, but it
causes many (13) of the regression tests to fail. Do you want to see
the regression.diffs?

Please.

regards, tom lane

At 11:06 PM 3/28/01 -0500, Tom Lane wrote:

Mark Knox <segfault@hardline.org> writes:

I don't think this solution would be valid on many other platforms.

Au contraire --- the ARM is the first platform I've heard of that does
not think sizeof(ItemPointerData) is 6. Else we'd have seen this
regress test fail before.

I meant I don't think *my* solution (ie packing the struct) would be valid anywhere else. It seems to be an arm-specific problem so maybe it needs an arm-specific patch? I've had to do this type of thing many times to get packages working properly in arm linux. It's a quirky platform.

Well, this patch seems to produce attlens of 6 as desired, but it
causes many (13) of the regression tests to fail. Do you want to see
the regression.diffs?

Please.

See attached.

Mark Knox <segfault@hardline.org> writes:

Well, this patch seems to produce attlens of 6 as desired, but it
causes many (13) of the regression tests to fail. Do you want to see
the regression.diffs?

Please.

See attached.

Does look pretty broken, but I don't see how my idea would have led to
all this other stuff failing. Anyway, I guess the path of least
resistance is to install your ARM-specific packing patch. It's
important to make sure that sizeof(ItemPointerData) is 6 if at all
possible, since it will cost you four or so wasted bytes in every
tuple header if it's not. Will take care of it for RC2.

regards, tom lane

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

Bottom line: 7.1RC1 passes most of the regression tests on
NetBSD/macppc. It's probably good enough for normal use since the
differences are not extensive, but someone would need to look at the
diff's for longer than the 10 seconds or so I've spent so far, and
someone should actually set it up for real use to check that.

I used the vanilla tarball from postgresql.org, not the NetBSD package system.

Details: It's clearly less clean than the OS X build. Also my G4
desktop runs rings around both a Sun Ultra 1 and the 8500 I have
NetBSD on for stuff like this build.

I'm actually reevaluating how much I want to keep running real open
source OS's vs the partly open MacOS X when both the OS and this
application runs so much cleaner on the most recent (fastest)
hardware. I like Apple stuff, but I never thought I would be this
impressed with OS X this quickly. I guess I should shut up now or
risk a flame war since the point is the PG port quality and not how
good the target platform is.

% gmake check
gmake -C ../../../contrib/spi REFINT_VERBOSE=1 refint.so autoinc.so
gmake[1]: Entering directory `/usr/local/dist/postgresql-7.1RC1/contrib/spi'
gmake[1]: `refint.so' is up to date.
gmake[1]: `autoinc.so' is up to date.
gmake[1]: Leaving directory `/usr/local/dist/postgresql-7.1RC1/contrib/spi'
/bin/sh ./pg_regress --temp-install --top-builddir=../../..
--schedule=./parallel_schedule --multibyte=
============== removing existing temp installation ==============
============== creating temporary installation ==============
============== initializing database system ==============
============== starting postmaster ==============
running on port 65432 with pid 21643
============== creating database "regression" ==============
CREATE DATABASE
============== installing PL/pgSQL ==============
============== running regression test queries ==============
parallel group (13 tests): text float4 varchar oid int2 char
boolean int4 int8 name float8 bit numeric
boolean ... ok
char ... ok
name ... ok
varchar ... ok
text ... ok
int2 ... ok
int4 ... ok
int8 ... ok
oid ... ok
float4 ... ok
float8 ... ok
bit ... ok
numeric ... ok
test strings ... ok
test numerology ... ok
parallel group (18 tests): path interval date time circle reltime
box lseg abstime inet point comments tinterval polygon timestamp
type_sanity oidjoins opr_sanity
point ... ok
lseg ... ok
box ... ok
path ... ok
polygon ... ok
circle ... ok
date ... ok
time ... ok
timestamp ... ok
interval ... ok
abstime ... ok
reltime ... ok
tinterval ... ok
inet ... ok
comments ... ok
oidjoins ... ok
type_sanity ... ok
opr_sanity ... ok
test geometry ... FAILED
test horology ... FAILED
test create_function_1 ... ok
test create_type ... ok
test create_table ... ok
test create_function_2 ... ok
test copy ... ok
parallel group (7 tests): create_operator create_aggregate inherit
triggers constraints create_misc create_index
constraints ... ok
triggers ... ok
create_misc ... ok
create_aggregate ... ok
create_operator ... ok
create_index ... ok
inherit ... ok
test create_view ... ok
test sanity_check ... ok
test errors ... ok
test select ... ok
parallel group (16 tests): arrays select_having select_distinct
transactions random portals select_into union select_distinct_on
select_implicit case subselect aggregates btree_index join hash_index
select_into ... ok
select_distinct ... ok
select_distinct_on ... ok
select_implicit ... ok
select_having ... ok
subselect ... ok
union ... ok
case ... ok
join ... ok
aggregates ... ok
transactions ... ok
random ... ok
portals ... ok
arrays ... ok
btree_index ... ok
hash_index ... ok
test misc ... ok
parallel group (5 tests): portals_p2 alter_table foreign_key
select_views rules
select_views ... ok
alter_table ... ok
portals_p2 ... ok
rules ... ok
foreign_key ... ok
parallel group (3 tests): temp limit plpgsql
limit ... ok
plpgsql ... ok
temp ... ok
============== shutting down postmaster ==============

=======================
2 of 76 tests failed.
=======================

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

The diff is:

*** ./expected/geometry-positive-zeros.out      Tue Sep 12 14:07:16 2000
--- ./results/geometry.out      Thu Apr  5 08:29:58 2001
***************
*** 445,451 ****

-----+---------------------------------------------------------------- 
---------------------------------------------------------------------- 
---------------------------------------------------------------------- 
---------------------------------------------------------------------- 
---------------------------------------------------------------------- 
-------------------------------------
| 
((-3,0),(-2.59807621135076,1.50000000000442),(-1.49999999999116,2.5980 
7621135842),(1.53102359017709e-11,3),(1.50000000001768,2.5980762113431 
1),(2.59807621136607,1.4999999999779),(3,-3.06204718035418e-11),(2.598 
07621133545,-1.50000000003094),(1.49999999996464,-2.59807621137373),(- 
4.59307077053127e-11,-3),(-1.5000000000442,-2.5980762113278),(-2.59807 
621138138,-1.49999999995138))
| 
((-99,2),(-85.6025403783588,52.0000000001473),(-48.9999999997054,88.60 
2540378614),(1.00000000051034,102),(51.0000000005893,88.6025403781036) 
,(87.6025403788692,51.9999999992634),(101,1.99999999897932),(87.602540 
3778485,-48.0000000010313),(50.9999999988214,-84.6025403791243),(0.999 
999998468976,-98),(-49.0000000014732,-84.6025403775933),(-85.602540379 
3795,-47.9999999983795))
!      | 
((-4,3),(-3.33012701891794,5.50000000000737),(-1.49999999998527,7.3301 
270189307),(1.00000000002552,8),(3.50000000002946,7.33012701890518),(5 
.33012701894346,5.49999999996317),(6,2.99999999994897),(5.330127018892 
42,0.499999999948437),(3.49999999994107,-1.33012701895622),(0.99999999 
9923449,-2),(-1.50000000007366,-1.33012701887967),(-3.33012701896897,0 
.500000000081028))
| 
((-2,2),(-1.59807621135076,3.50000000000442),(-0.499999999991161,4.598 
07621135842),(1.00000000001531,5),(2.50000000001768,4.59807621134311), 
(3.59807621136607,3.4999999999779),(4,1.99999999996938),(3.59807621133 
545,0.499999999969062),(2.49999999996464,-0.598076211373729),(0.999999 
999954069,-1),(-0.500000000044197,-0.598076211327799),(-1.598076211381 
38,0.500000000048616))
| 
((90,200),(91.3397459621641,205.000000000015),(95.0000000000295,208.66 
0254037861),(100.000000000051,210),(105.000000000059,208.66025403781), 
(108.660254037887,204.999999999926),(110,199.999999999898),(108.660254 
037785,194.999999999897),(104.999999999882,191.339745962088),(99.99999 
99998469,190),(94.9999999998527,191.339745962241),(91.3397459620621,19 
5.000000000162))
| 
((0,0),(13.3974596216412,50.0000000001473),(50.0000000002946,86.602540 
378614),(100.00000000051,100),(150.000000000589,86.6025403781036),(186 
.602540378869,49.9999999992634),(200,-1.02068239345139e-09),(186.60254 
0377848,-50.0000000010313),(149.999999998821,-86.6025403791243),(99.99 
9999998469,-100),(49.9999999985268,-86.6025403775933),(13.397459620620 
5,-49.9999999983795))
--- 445,451 ----

-----+----------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
-------------------------------------
|
((-3,0),(-2.59807621135076,1.50000000000442),(-1.49999999999116,2.5980
7621135842),(1.53102359017709e-11,3),(1.50000000001768,2.5980762113431
1),(2.59807621136607,1.4999999999779),(3,-3.06204718035418e-11),(2.598
07621133545,-1.50000000003094),(1.49999999996464,-2.59807621137373),(-
4.59307077053127e-11,-3),(-1.5000000000442,-2.5980762113278),(-2.59807
621138138,-1.49999999995138))
|
((-99,2),(-85.6025403783588,52.0000000001473),(-48.9999999997054,88.60
2540378614),(1.00000000051034,102),(51.0000000005893,88.6025403781036)
,(87.6025403788692,51.9999999992634),(101,1.99999999897932),(87.602540
3778485,-48.0000000010313),(50.9999999988214,-84.6025403791243),(0.999
999998468976,-98),(-49.0000000014732,-84.6025403775933),(-85.602540379
3795,-47.9999999983795))
! |
((-4,3),(-3.33012701891794,5.50000000000737),(-1.49999999998527,7.3301
270189307),(1.00000000002552,8),(3.50000000002946,7.33012701890518),(5
.33012701894346,5.49999999996317),(6,2.99999999994897),(5.330127018892
42,0.499999999948437),(3.49999999994107,-1.33012701895622),(0.99999999
9923449,-2),(-1.50000000007366,-1.33012701887966),(-3.33012701896897,0
.500000000081027))
|
((-2,2),(-1.59807621135076,3.50000000000442),(-0.499999999991161,4.598
07621135842),(1.00000000001531,5),(2.50000000001768,4.59807621134311),
(3.59807621136607,3.4999999999779),(4,1.99999999996938),(3.59807621133
545,0.499999999969062),(2.49999999996464,-0.598076211373729),(0.999999
999954069,-1),(-0.500000000044197,-0.598076211327799),(-1.598076211381
38,0.500000000048616))
|
((90,200),(91.3397459621641,205.000000000015),(95.0000000000295,208.66
0254037861),(100.000000000051,210),(105.000000000059,208.66025403781),
(108.660254037887,204.999999999926),(110,199.999999999898),(108.660254
037785,194.999999999897),(104.999999999882,191.339745962088),(99.99999
99998469,190),(94.9999999998527,191.339745962241),(91.3397459620621,19
5.000000000162))
|
((0,0),(13.3974596216412,50.0000000001473),(50.0000000002946,86.602540
378614),(100.00000000051,100),(150.000000000589,86.6025403781036),(186
.602540378869,49.9999999992634),(200,-1.02068239345139e-09),(186.60254
0377848,-50.0000000010313),(149.999999998821,-86.6025403791243),(99.99
9999998469,-100),(49.9999999985268,-86.6025403775933),(13.397459620620
5,-49.9999999983795))

======================================================================

*** ./expected/horology.out     Sun Dec  3 06:51:11 2000
--- ./results/horology.out      Thu Apr  5 08:30:01 2001
***************
*** 122,128 ****
SELECT time with time zone '01:30' + interval '02:01' AS "03:31:00-08";
03:31:00-08
-------------
!  03:31:00-08
(1 row)

SELECT time with time zone '01:30-08' - interval '02:01' AS "23:29:00-08";
--- 122,128 ----
SELECT time with time zone '01:30' + interval '02:01' AS "03:31:00-08";
03:31:00-08
-------------
!  03:31:00-07
(1 row)

SELECT time with time zone '01:30-08' - interval '02:01' AS "23:29:00-08";
***************
*** 140,146 ****
SELECT time with time zone '03:30' + interval '1 month 04:01' AS
"07:31:00-08";
07:31:00-08
-------------
! 07:31:00-08
(1 row)

SELECT interval '04:30' - time with time zone '01:02' AS "+03:28";
--- 140,146 ----
SELECT time with time zone '03:30' + interval '1 month 04:01' AS 
"07:31:00-08";
07:31:00-08
-------------
!  07:31:00-07
(1 row)

SELECT interval '04:30' - time with time zone '01:02' AS "+03:28";

======================================================================

During the build I got these ugly, but presumably harmless complaints:

gmake[4]: Entering directory
`/usr/local/dist/postgresql-7.1RC1/src/pl/plpgsql/src'
gcc -c -I. -I../../../../src/include -O2 -pipe -Wall
-Wmissing-prototypes -Wmissing-declarations -fpic -DPIC -o
pl_parse.o pl_gram.c
lex.plpgsql_yy.c: In function `plpgsql_yylex':
lex.plpgsql_yy.c:971: warning: label `find_rule' defined but not used
lex.plpgsql_yy.c: At top level:
lex.plpgsql_yy.c:2223: warning: `plpgsql_yy_flex_realloc' defined but not used

in a few places, and

gcc -O2 -pipe -Wall -Wmissing-prototypes -Wmissing-declarations
-I../../../src/interfaces/libpq -I../../../src/include -c -o
tab-complete.o tab-complete.c
tab-complete.c: In function `initialize_readline':
tab-complete.c:103: warning: assignment from incompatible pointer type
tab-complete.c: In function `psql_completion':
tab-complete.c:292: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:296: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:301: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:309: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:320: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:325: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:332: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:337: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:342: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:347: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:350: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:366: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:371: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:378: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:381: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:392: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:400: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:406: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:410: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:413: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:420: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:423: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:429: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:435: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:440: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:448: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:455: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:460: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:465: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:473: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:478: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:490: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:493: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:496: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:506: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:514: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:521: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:532: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:541: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:545: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:553: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:556: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:559: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:569: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:572: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:578: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:582: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:587: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:592: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:599: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:604: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:606: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:608: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:619: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:622: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:626: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:634: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:640: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:646: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:651: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:660: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:666: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:672: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:678: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:682: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:687: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:690: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:698: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:702: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:704: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:709: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:714: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:716: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:718: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:725: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:749: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:763: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
gcc -O2 -pipe -Wall -Wmissing-prototypes -Wmissing-declarations
command.o common.o help.o input.o stringutils.o mainloop.o copy.o
startup.o prompt.o variables.o large_obj.o print.o describe.o
tab-complete.o -L../../../src/interfaces/libpq -lpq
-Wl,-R/usr/local/lib -lz -lcrypt -lresolv -lcompat -lm -lutil -ledit
-ltermcap -o psql
gmake[3]: Leaving directory `/usr/local/dist/postgresql-7.1RC1/src/bin/psql'

Great work as always. It's been nice to see the progressive
improvement in the portability and quality of the DBMS over the years.

Signature held pending an ISO 9000 compliant
signature design and approval process.
h.b.hotz@jpl.nasa.gov, or hbhotz@oxy.edu