Thread

Call for platforms

Thomas Lockhart <lockhart@alumni.caltech.edu> — 2001-03-21T01:05:01Z

OK, here is my current platform list taken from the -hackers list and
from Vince's web page. I'm sure I've missed at least a few reports, but
please confirm that platforms are actually running and passing
regression tests with recent betas or the latest release candidate.

If a platform you are running on is not listed, make sure it gets
included! Platforms with reports for 7.0 risk being demoted to the "used
to be supported list", and platforms with reports for only 6.5 are on a
deathwatch, so be sure to speak up! Also, I've included names below to
remind us who helped last time, but feel free to report even if your
name is not already listed.

I've separated out recent reports and put them at the end of the list.
Thanks in advance.

                   - Thomas

AIX 4.3.2  RS6000  7.0 2000-04-05, Andreas Zeugswetter
Compaq Tru64 5.0 Alpha 7.0 2000-04-11, Andrew McMurry
IRIX 6.5.6f MIPS   6.5.3 2000-02-18, Kevin Wheatley
Linux 2.2.x armv4l 7.0 2000-04-17, Mark Knox
Linux 2.0.x MIPS   7.0 2000-04-13, Tatsuo Ishii
mklinux PPC750     7.0 2000-04-13, Tatsuo Ishii
NetBSD 1.4 arm32   7.0 2000-04-08, Patrick Welche
NetBSD 1.4U x86    7.0 2000-03-26, Patrick Welche
NetBSD m68k        7.0 2000-04-10, Henry B. Hotz
NetBSD Sparc       7.0 2000-04-13, Tom I. Helbekkmo
QNX 4.25 x86       7.0 2000-04-01, Dr. Andreas Kardos
SCO OpenServer 5 x86 6.5 1999-05-25, Andrew Merrill
Solaris x86        7.0 2000-04-12, Marc Fournier
Solaris 2.5.1-2.7 Sparc 7.0 2000-04-12, Peter Eisentraut
SunOS 4.1.4 Sparc  7.0 2000-04-13, Tatsuo Ishii
Windows/Win32 x86  7.0 2000-04-02, Magnus Hagander (clients only)
WinNT/Cygwin x86   7.0 2000-03-30, Daniel Horak

BeOS 5.0.3 x86     7.1 2000-12-18, Cyril Velter
BSDI 4.01  x86     7.1 2001-03-19, Bruce Momjian
FreeBSD 4.2 x86    7.1 2001-03-19, Vince Vielhaber
HPUX 10.20 PA-RISC 7.1 2001-03-19, Tom Lane
IBM        S/390   7.1 2000-11-17, Neale Ferguson
Linux 2.2.x Alpha  7.1 2001-01-23, Ryan Kirkpatrick
Linux 2.2.16 x86   7.1 2001-03-19, Thomas Lockhart
Linux 2.2.15 Sparc 7.1 2001-01-30, Ryan Kirkpatrick
LinuxPPC G3        7.1 2001-03-19, Tom Lane
SCO UnixWare 7.1.1 x86 7.1 2001-03-19, Larry Rosenman
MacOS-X Darwin PowerPC 7.1 2000-12-11, Peter Bierman

Re: Call for platforms

Larry Rosenman <ler@lerctr.org> — 2001-03-21T02:09:11Z

* 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

Re: Call for platforms

Thomas Lockhart <lockhart@alumni.caltech.edu> — 2001-03-21T02:39:49Z

> 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

Re: Call for platforms

Tatsuo Ishii <t-ishii@sra.co.jp> — 2001-03-21T06:36:07Z

> 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

Re: Call for platforms

Adriaan Joubert <a.joubert@albourne.com> — 2001-03-21T06:46:48Z

> 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

Re: Call for platforms

Tatsuo Ishii <t-ishii@sra.co.jp> — 2001-03-21T07:30:33Z

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

Re: Call for platforms

Tom Lane <tgl@sss.pgh.pa.us> — 2001-03-21T11:13:46Z

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

Re: Call for platforms

Tatsuo Ishii <t-ishii@sra.co.jp> — 2001-03-21T14:04:12Z

> 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

Re: Call for platforms

Gilles Darold <gilles@darold.net> — 2001-03-21T18:20:06Z

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

Re: Re: Call for platforms

Peter Eisentraut <peter_e@gmx.net> — 2001-03-21T18:24:17Z

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/

Re: Call for platforms

Gilles Darold <gilles@darold.net> — 2001-03-21T19:45:03Z

Hi,

I am currently testing beta6 on AIX 4.3.3 on a RS6000 H80 with 4 cpu and 4
Go RAM
I use :

./configure
        --with-CC=/usr/local/bin/gcc
        --with-includes=/usr/local/include
        --with-libraries=/usr/local/lib

All seem to be ok, There just the geometry failure in regression test
(following the AIX FAQ
it's normal ?)

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

make[4]: cc : Command not found

Any idea ?


Gilles DAROLD

> Hi,
>
> I reported Linux RedHat 6.2 - 2.2.14-5.0smp #1 SMP Tue Mar 7 21:01:40 EST
> 2000 i686
> 2 cpu - 1Go RAM
>
> Gilles DAROLD
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://www.postgresql.org/search.mpl

Re: [HACKERS] Call for platforms AIX 4.3.3 Failed

Gilles Darold <gilles@darold.net> — 2001-03-21T20:53:46Z

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

Re: Re: [HACKERS] Call for platforms AIX 4.3.3 Failed

Peter Eisentraut <peter_e@gmx.net> — 2001-03-21T21:25:55Z

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/

Re:Call for platforms AIX 4.3.3 Failed

Gilles Darold <gilles@darold.net> — 2001-03-21T21:37:39Z

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 ?

Re: Call for platforms (linux 2.4.x ?)

Franck Martin <franck@sopac.org> — 2001-03-22T00:31:03Z

I see nobody did a test of 7.1 on Linux 2.4.x ?

Would be nice to certify it is running on kernel 2.4.x as they claim this
is entreprise strength kernel...

Cheers.

Thomas Lockhart wrote:

>
>
> AIX 4.3.2  RS6000  7.0 2000-04-05, Andreas Zeugswetter
> Compaq Tru64 5.0 Alpha 7.0 2000-04-11, Andrew McMurry
> IRIX 6.5.6f MIPS   6.5.3 2000-02-18, Kevin Wheatley
> Linux 2.2.x armv4l 7.0 2000-04-17, Mark Knox
> Linux 2.0.x MIPS   7.0 2000-04-13, Tatsuo Ishii
> mklinux PPC750     7.0 2000-04-13, Tatsuo Ishii
> NetBSD 1.4 arm32   7.0 2000-04-08, Patrick Welche
> NetBSD 1.4U x86    7.0 2000-03-26, Patrick Welche
> NetBSD m68k        7.0 2000-04-10, Henry B. Hotz
> NetBSD Sparc       7.0 2000-04-13, Tom I. Helbekkmo
> QNX 4.25 x86       7.0 2000-04-01, Dr. Andreas Kardos
> SCO OpenServer 5 x86 6.5 1999-05-25, Andrew Merrill
> Solaris x86        7.0 2000-04-12, Marc Fournier
> Solaris 2.5.1-2.7 Sparc 7.0 2000-04-12, Peter Eisentraut
> SunOS 4.1.4 Sparc  7.0 2000-04-13, Tatsuo Ishii
> Windows/Win32 x86  7.0 2000-04-02, Magnus Hagander (clients only)
> WinNT/Cygwin x86   7.0 2000-03-30, Daniel Horak
>
> BeOS 5.0.3 x86     7.1 2000-12-18, Cyril Velter
> BSDI 4.01  x86     7.1 2001-03-19, Bruce Momjian
> FreeBSD 4.2 x86    7.1 2001-03-19, Vince Vielhaber
> HPUX 10.20 PA-RISC 7.1 2001-03-19, Tom Lane
> IBM        S/390   7.1 2000-11-17, Neale Ferguson
> Linux 2.2.x Alpha  7.1 2001-01-23, Ryan Kirkpatrick
> Linux 2.2.16 x86   7.1 2001-03-19, Thomas Lockhart
> Linux 2.2.15 Sparc 7.1 2001-01-30, Ryan Kirkpatrick
> LinuxPPC G3        7.1 2001-03-19, Tom Lane
> SCO UnixWare 7.1.1 x86 7.1 2001-03-19, Larry Rosenman
> MacOS-X Darwin PowerPC 7.1 2000-12-11, Peter Bierman
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/users-lounge/docs/faq.html

Re: Call for platforms (linux 2.4.x ?)

Trond Eivind Glomsrød <teg@redhat.com> — 2001-03-22T00:31:13Z

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.

Re: Call for platforms

Tom Lane <tgl@sss.pgh.pa.us> — 2001-03-22T03:29:05Z

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

Re: Call for platforms

Larry Rosenman <ler@lerctr.org> — 2001-03-22T03:31:09Z

* 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

Re: Call for platforms (linux 2.4.x ?)

Roberto Mello <rmello@cc.usu.edu> — 2001-03-22T05:48:36Z

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

Re: Call for platforms

Marko Kreen <marko@l-t.ee> — 2001-03-22T10:02:09Z

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

Re: Call for platforms

Thomas Lockhart <lockhart@alumni.caltech.edu> — 2001-03-22T14:29:59Z

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

Re: Call for platforms

Marc G. Fournier <scrappy@hub.org> — 2001-03-22T14:39:33Z

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

Re: Call for platforms

Thomas Lockhart <lockhart@alumni.caltech.edu> — 2001-03-22T14:50:26Z

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

Re: Re: Call for platforms

Marc G. Fournier <scrappy@hub.org> — 2001-03-22T15:06:31Z

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

Re: Re: Call for platforms

Thomas Lockhart <lockhart@alumni.caltech.edu> — 2001-03-22T15:15:40Z

> 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

Re: Re: Call for platforms

Larry Rosenman <ler@lerctr.org> — 2001-03-22T15:23:04Z

4.3 is in RELEASE CANDIDATE right now.  By the time we release, it should 
be -RELEASE or -STABLE. 

I'd include it as just 4.3. 

It will be the -RELEASE at the time we are.

LER

>>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<

On 3/22/01, 8:50:26 AM, Thomas Lockhart <lockhart@alumni.caltech.edu> wrote 
regarding [HACKERS] Re: Call for platforms:


> > > FreeBSD 4.2 x86    7.1 2001-03-19, Vince Vielhaber
> > FreeBSD 4.3-BETA is good to go also ...

> Yeah, I'm not sure how to list that, or whether to bother. It is beta,
> 4.2 works fine (and nothing had to change for 4.3, right?) so maybe we
> just list it when 4.3 goes stable? Or is 4.3 sufficiently different that
> it would be good to list in the comments for the platform?

>                           - Thomas

> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster

Re: Re: Call for platforms

Marc G. Fournier <scrappy@hub.org> — 2001-03-22T15:31:07Z

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

Re: Re: Call for platforms

Tom Lane <tgl@sss.pgh.pa.us> — 2001-03-22T15:52:10Z

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

Re: Re: Call for platforms

bpalmer <bpalmer@crimelabs.net> — 2001-03-22T15:53:16Z

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

Re: Re: Call for platforms

Thomas Lockhart <lockhart@alumni.caltech.edu> — 2001-03-22T15:54:56Z

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

Re: Re: Call for platforms

Marc G. Fournier <scrappy@hub.org> — 2001-03-22T15:56:34Z

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

Re: Re: Call for platforms

Tom Lane <tgl@sss.pgh.pa.us> — 2001-03-22T16:08:07Z

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

Re: Re: Call for platforms

bpalmer <bpalmer@crimelabs.net> — 2001-03-22T16:08:11Z

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

Re: Re: Call for platforms

Peter Eisentraut <peter_e@gmx.net> — 2001-03-22T16:20:03Z

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/

Re: Call for platforms

Peter Eisentraut <peter_e@gmx.net> — 2001-03-22T16:25:01Z

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/

Re: Call for platforms

Peter Eisentraut <peter_e@gmx.net> — 2001-03-22T16:29:27Z

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/

Re: Re: Call for platforms

Peter Eisentraut <peter_e@gmx.net> — 2001-03-22T16:30:46Z

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/

Re: Re: Call for platforms

Peter Eisentraut <peter_e@gmx.net> — 2001-03-22T16:33:38Z

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/

Re: Call for platforms

Marko Kreen <marko@l-t.ee> — 2001-03-22T17:12:39Z

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

Re: Re: Call for platforms

Marc G. Fournier <scrappy@hub.org> — 2001-03-22T17:29:47Z

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>

Re: Re: Call for platforms

Tom Lane <tgl@sss.pgh.pa.us> — 2001-03-22T17:49:39Z

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

Re: Call for platforms

Patrick Welche <prlw1@newn.cam.ac.uk> — 2001-03-22T17:54:18Z

Just a data point on the geometry test under NetBSD/i386 issue:

/etc/ld.so.conf by default now contains:
libm.so.0       machdep.fpu_present     1:libm387.so.0,libm.so.0

which means that if the sysctl machdep.fpu_present returns 1, load the
shared library libm387 to make use of the fpu.

If you remove /etc/ld.so.conf, so that ldd `which psql` does not show

         -lm.0 => /usr/lib/libm387.so.0
         -lm.0 => /usr/lib/libm.so.0

but only the libm.so.0 line

======================
 All 76 tests passed. 
======================

If you replace the /etc/ld.so.conf file and have an fpu, then the geometry
test will fail with slightly different rounding.

Do we want a specific geometry-netbsd-i386-with-fpu.out where you must
also test

% sysctl machdep.fpu_present
machdep.fpu_present = 1

?

Cheers,

Patrick

PS: AFAIK geometry-positive-zeros-bsd works for all NetBSD platforms - the
above difference is only for i386 + fpu.

On Thu, Mar 22, 2001 at 07:12:39PM +0200, Marko Kreen wrote:
> On Thu, Mar 22, 2001 at 05:25:01PM +0100, Peter Eisentraut wrote:
> > Marko Kreen writes:
> > >
> > > OK?: NetBSD 1.5 i586 / egcs 2.91.66 / (netbsd-1-5 from Jan)
> > >
> > > netbsd FAILED the geometry test, diff attached, dunno if its
> > > critical or not.
> > 
> > Can you check whether it matches any of the other possible geometry
> > results?  See
> 
> Yes, it matches geometry-positive-zeros-bsd.out.  There is
> another report about NetBSD 1.5/i386 which has comment:
> 
> > one spurious floating point test failure
> > (mail sent to postgresql-bugs with details)
> 
> But I could not find it in archive page.  (reporter Giles Lean
> <giles@nemeton.com.au>)  Perhaps same thing?
> 
> -- 
> marko
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

Re: Re: Call for platforms

Karl DeBisschop <kdebisschop@alert.infoplease.com> — 2001-03-22T19:43:27Z

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

Re: Re: Call for platforms

Patrick Welche <prlw1@newn.cam.ac.uk> — 2001-03-22T20:33:55Z

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

Re: Call for platforms

Trond Eivind Glomsrød <teg@redhat.com> — 2001-03-22T21:02:11Z

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.

Re: Re: Call for platforms

Marc G. Fournier <scrappy@hub.org> — 2001-03-22T21:44:47Z

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

Re: Call for platforms

Trond Eivind Glomsrød <teg@redhat.com> — 2001-03-22T22:46:18Z

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.

Re: Call for platforms

Vince Vielhaber <vev@michvhf.com> — 2001-03-23T01:29:20Z

On 22 Mar 2001, Trond Eivind [iso-8859-1] Glomsrd wrote:

> teg@redhat.com (Trond Eivind Glomsrd) 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
==========================================================================

Re: Call for platforms

segfault@hardline.org — 2001-03-23T03:49:02Z

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

Re: Call for platforms

Tatsuo Ishii <t-ishii@sra.co.jp> — 2001-03-23T05:31:27Z

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

Re: Call for platforms

Tom Lane <tgl@sss.pgh.pa.us> — 2001-03-23T06:08:06Z

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

Re: Call for platforms

Thomas Lockhart <lockhart@alumni.caltech.edu> — 2001-03-23T06:31:43Z

> 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

Re: Re: Call for platforms

Tatsuo Ishii <t-ishii@sra.co.jp> — 2001-03-23T07:11:18Z

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

Re: Call for platforms

Tatsuo Ishii <t-ishii@sra.co.jp> — 2001-03-23T08:19:17Z

> 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

Re: Call for platforms

Tom Lane <tgl@sss.pgh.pa.us> — 2001-03-23T08:33:03Z

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

Re: Call for platforms

Tatsuo Ishii <t-ishii@sra.co.jp> — 2001-03-23T08:45:28Z

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

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

Re: Call for platforms

Trond Eivind Glomsrød <teg@redhat.com> — 2001-03-23T15:35:34Z

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.

Re: Call for platforms

Vince Vielhaber <vev@michvhf.com> — 2001-03-23T15:48:24Z

On 23 Mar 2001, Trond Eivind [iso-8859-1] Glomsrd wrote:

> Vince Vielhaber <vev@michvhf.com> writes:
>
> > On 22 Mar 2001, Trond Eivind [iso-8859-1] Glomsrd wrote:
> >
> > > teg@redhat.com (Trond Eivind Glomsrd) 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
==========================================================================

Re: Re: Call for platforms

bpalmer <bpalmer@crimelabs.net> — 2001-03-23T17:38:16Z

> 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

Re: Re: Call for platforms

Tom Lane <tgl@sss.pgh.pa.us> — 2001-03-23T20:08:27Z

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

Re: Call for platforms

Peter Eisentraut <peter_e@gmx.net> — 2001-03-24T09:38:04Z

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/

Re: Re: Call for platforms

Peter Eisentraut <peter_e@gmx.net> — 2001-03-24T10:18:11Z

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/

Re: Re: Call for platforms

Tom Lane <tgl@sss.pgh.pa.us> — 2001-03-24T16:18:57Z

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

Re: Call for platforms

Tom Lane <tgl@sss.pgh.pa.us> — 2001-03-24T18:31:07Z

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

Re: Call for platforms

Alexander Klimov <ask@wisdom.weizmann.ac.il> — 2001-03-25T16:57:24Z

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

Re: Re: Call for platforms

Tom Lane <tgl@sss.pgh.pa.us> — 2001-03-25T17:24:10Z

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

Re: Re: Call for platforms

Doug McNaught <doug@wireboard.com> — 2001-03-25T18:25:00Z

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

Re: Re: Call for platforms

Tom Lane <tgl@sss.pgh.pa.us> — 2001-03-25T18:26:47Z

> 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

Re: Re: Call for platforms

Tom Lane <tgl@sss.pgh.pa.us> — 2001-03-25T20:02:42Z

"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

Re: Re: Call for platforms

segfault@hardline.org — 2001-03-25T20:37:23Z

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

Re: Re: Call for platforms

Tom Lane <tgl@sss.pgh.pa.us> — 2001-03-25T21:07:13Z

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

Re: Call for platforms

Ryan Kirkpatrick <pgsql@rkirkpat.net> — 2001-03-26T03:49:56Z

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

Re: Call for platforms

Adriaan Joubert <a.joubert@albourne.com> — 2001-03-26T06:24:36Z

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

Re: Re: Call for platforms

Thomas Lockhart <lockhart@alumni.caltech.edu> — 2001-03-26T16:18:33Z

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

Re: Call for platforms

Thomas Lockhart <lockhart@alumni.caltech.edu> — 2001-03-26T17:14:17Z

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

Re: Re: Call for platforms

Peter Eisentraut <peter_e@gmx.net> — 2001-03-26T18:01:47Z

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/

Re: Re: Call for platforms

Thomas Lockhart <lockhart@alumni.caltech.edu> — 2001-03-26T18:05:55Z

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

Re: Re: Call for platforms

Larry Rosenman <ler@lerctr.org> — 2001-03-26T18:09:05Z

Since the SCO UDK works on both UnixWare and OpenServer, I think we are 
pretty safe.  Also, there was a post to -HACKERS about the accept bug and 
we changed the workaround to include OSR5. 

I'd leave it until disproved.  I don't have a OSR5 installation to check 
it with, however. 

LER

>>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<

On 3/26/01, 12:05:55 PM, Thomas Lockhart <lockhart@alumni.caltech.edu> 
wrote regarding Re: [HACKERS] Re: Call for platforms:


> > > SCO OpenServer 5 x86   7.1 2001-03-13, Billy Allie
> > Where did you see this?  I don't find it in the archives or in Vince's
> > database.

> In FAQ_SCO. I was looking to try to figure out what the differences were
> between the SCO products :)

>                    - Thomas

> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

Re: Re: Call for platforms

Tom Lane <tgl@sss.pgh.pa.us> — 2001-03-26T18:22:56Z

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

Re: Re: Call for platforms

Tom Lane <tgl@sss.pgh.pa.us> — 2001-03-26T18:30:44Z

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

Re: Re: Call for platforms

Peter Eisentraut <peter_e@gmx.net> — 2001-03-26T19:03:19Z

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/

Re: Re: Call for platforms

Thomas Lockhart <lockhart@alumni.caltech.edu> — 2001-03-26T20:36:19Z

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

Re: Re: Call for platforms

Thomas Lockhart <lockhart@alumni.caltech.edu> — 2001-03-26T20:39:10Z

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

Re: Re: Call for platforms

Thomas Lockhart <lockhart@alumni.caltech.edu> — 2001-03-26T20:43:11Z

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

Re: Re: Call for platforms

Thomas Lockhart <lockhart@alumni.caltech.edu> — 2001-03-26T21:39:38Z

> 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

Re: Re: Call for platforms

Larry Rosenman <ler@lerctr.org> — 2001-03-26T21:41:28Z

I would..... 

LER

-- 
Larry Rosenman                                                            
         http://www.lerctr.org/~ler/
Phone: +1 972 414 9812                                                    
         E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 US

>>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<

On 3/26/01, 2:36:19 PM, Thomas Lockhart <lockhart@alumni.caltech.edu> wrote 
regarding Re: [HACKERS] Re: Call for platforms:


> > "PPC750"?  What's that?  "PPC G3" might be more likely to mean something
> > to onlookers ...

> Actually "G3" means nothing outside of Apple afaict. The 750 series is a
> follow-on to the 60x series, and there is a 7xxx series also. From my
> pov, using an accepted label, rather than a marketing (re)label, better
> indicates *what* this actually can run on. I'm not sure that I have it
> labeled correctly yet, but "G3" is not a step in the right direction.

> As we both found, it is difficult to wade through Apple's own docs to
> decipher which processor is actually built into the system.

> Should I put "Mac G3" in the comment section?

>                        - Thomas

> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly

Re: Call for platforms

Thomas Lockhart <lockhart@alumni.caltech.edu> — 2001-03-26T21:50:17Z

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

Re: Re: Call for platforms

Tom Lane <tgl@sss.pgh.pa.us> — 2001-03-26T22:15:12Z

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

Re: Re: Call for platforms

Mathijs Brands <mathijs@ilse.nl> — 2001-03-26T22:26:13Z

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

Re: Re: Call for platforms

Lamar Owen <lamar.owen@wgcr.org> — 2001-03-26T22:27:04Z

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

Re: Re: Call for platforms

Trond Eivind Glomsrød <teg@redhat.com> — 2001-03-26T22:31:42Z

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.

Re: Re: Call for platforms

Vince Vielhaber <vev@michvhf.com> — 2001-03-26T22:41:31Z

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

Re: Re: Call for platforms

Mathijs Brands <mathijs@ilse.nl> — 2001-03-26T22:46:15Z

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)

Re: Re: Call for platforms

Lamar Owen <lamar.owen@wgcr.org> — 2001-03-26T22:48:21Z

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

Re: Call for platforms

Henry B. Hotz <hotz@jpl.nasa.gov> — 2001-03-26T23:00:27Z

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

Re: Call for platforms

Thomas Lockhart <lockhart@alumni.caltech.edu> — 2001-03-26T23:06:18Z

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

Re: Re: Call for platforms

Thomas Lockhart <lockhart@alumni.caltech.edu> — 2001-03-26T23:08:27Z

> 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

Re: Re: Call for platforms

Tom Lane <tgl@sss.pgh.pa.us> — 2001-03-26T23:35:59Z

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

Re: Re: Call for platforms

Mathijs Brands <mathijs@ilse.nl> — 2001-03-27T00:05:34Z

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

Re: Re: Call for platforms

Tom Lane <tgl@sss.pgh.pa.us> — 2001-03-27T00:09:38Z

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

Re: Re: Call for platforms

Tom Lane <tgl@sss.pgh.pa.us> — 2001-03-27T00:53:44Z

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

Regression test on FBSD 3.3 & 4.2, IRIX 6.5 (was Re: Re: Call for platforms)

Mathijs Brands <mathijs@ilse.nl> — 2001-03-27T01:04:50Z

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

Re: Re: Call for platforms

Mathijs Brands <mathijs@ilse.nl> — 2001-03-27T01:08:11Z

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

Re: Re: Call for platforms

Peter Bierman <bierman@apple.com> — 2001-03-27T01:08:38Z

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

Re: Regression test on FBSD 3.3 & 4.2, IRIX 6.5 (was Re: Re: Call for platforms)

Tom Lane <tgl@sss.pgh.pa.us> — 2001-03-27T01:20:08Z

Mathijs Brands <mathijs@ilse.nl> writes:
> Notice the single underscore before volatile.

That's definitely wrong --- fixed.

> Fixing this causes
> as (the SGI version, not GNU as) to choke on the '.global tas' statement.

> s_lock.c: At top level:
> s_lock.c:234: warning: `tas_dummy' defined but not used
> as: Error: /var/tmp/ccoUdrOb.s, line 421: undefined assembler operation: .global
>       .global tas
> gmake[4]: *** [s_lock.o] Error 1

Perhaps it should be ".globl"?  That's another common spelling.

Do you know whether anyone uses the GNU assembler on this platform,
or is it always SGI's?  I'm wondering if we need two versions of the
assembly code ...

I had missed the fact that s_lock.c contains some MIPS code.  Anyone
have any idea what versions of the MIPS series this code runs on?

			regards, tom lane

Re: Regression test on FBSD 3.3 & 4.2, IRIX 6.5 (was Re: Re: Call for platforms)

Thomas Lockhart <lockhart@alumni.caltech.edu> — 2001-03-27T01:35:01Z

> 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

Re: MIPS test-and-set

Nathan Myers <ncm@zembu.com> — 2001-03-27T01:41:34Z

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

Re: Re: Call for platforms

Justin Clift <aa2@bigpond.net.au> — 2001-03-27T01:59:36Z

Hi,

I tested Solaris 8 SPARC (32 bit) over the weekend, and can test Solaris
8 INTEL this week/weekend.

The results of Solaris 8 SPARC were in Vince's database last time I
checked.  ???

+ Justin

Mathijs Brands wrote:
> 
> Hi
> 
> Is there a list somewhere listing the platforms 7.1 is being
> tested on right now? I'd be able to run regression tests on
> the following platforms, if necessary:
> 
>   FreeBSD 3.3 (x86)
>   FreeBSD 4.2 (x86)
>   Linux (x86 - 2.2 & 2.4 kernels, Redhat & Debian distro's)
>   Solaris 7 (SPARC)
>   Solaris 8 (x86)
>   Solaris 8 (SPARC)
>   IRIX 6.2
>   IRIX 6.5
> 
> If I can get the box back to working order, Alpha Linux is
> also an option. I'd be willing to build binary packages for
> Solaris and IRIX.
> 
> Regards,
> 
> Mathijs
> --
> "Books constitute capital."
>      Thomas Jefferson
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly

Re: Re: Call for platforms

Justin Clift <aa2@bigpond.net.au> — 2001-03-27T02:01:24Z

I know that Sourceforge has been adding all sorts of machines to their
compile farm.

Maybe it would be worthwhile taking a look if they have platforms we
don't?

Regards and best wishes,

Justin Clift

Thomas Lockhart wrote:
> 
> > The non-test-and-set case should work again in current CVS, and I'd
> > appreciate it if Alexander would verify that.  But as far as getting
> > some test-and-set support for MIPS goes, it looks like the only way
> > is for someone to sit down with a MIPS assembly manual.  I haven't
> > got one, nor access to a machine to test on...
> 
> That is not already available from the Irix support code?
> 
>                       - Thomas
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

Re: Call for platforms

tih@kpnqwest.no — 2001-03-27T02:38:50Z

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.

Re: Call for platforms

Jeff Duffy <jduffy@greatbridge.com> — 2001-03-27T03:01:19Z

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

Re: Re: Call for platforms

segfault@hardline.org — 2001-03-27T03:13:33Z

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

Re: Re: Call for platforms

Tom Lane <tgl@sss.pgh.pa.us> — 2001-03-27T04:14:42Z

"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

Re: MIPS test-and-set

Ian Lance Taylor <ian@airs.com> — 2001-03-27T05:18:43Z

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

Re: Call for platforms

Tatsuo Ishii <t-ishii@sra.co.jp> — 2001-03-27T08:57:24Z

> mklinux PPC750     7.0 2000-04-13, Tatsuo Ishii
> 
> Any luck with RC1?

I will try today or tomorrow...
--
Tatsuo Ishii

Re: Re: Call for platforms

Jeff Duffy <jeff@alanne.com> — 2001-03-27T10:42:59Z

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

Re: Re: Call for platforms

D'Arcy Cain <darcy@druid.net> — 2001-03-27T11:36:37Z

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.

Re: Re: Call for platforms

Mathijs Brands <mathijs@ilse.nl> — 2001-03-27T11:56:02Z

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

Re: Re: Call for platforms

Bruce Momjian <pgman@candle.pha.pa.us> — 2001-03-27T14:57:45Z

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

Re: Re: Call for platforms

Tom Lane <tgl@sss.pgh.pa.us> — 2001-03-27T15:36:26Z

Jeff Duffy <jduffy@greatbridge.com> writes:
> s_lock.c:235: parse error before `_volatile__'

That typo is fixed in current sources (should be OK in last night's
snapshot) but there's still some doubt as to how well the MIPS assembly
code works ...

			regards, tom lane

Re: Regression test on FBSD 3.3 & 4.2, IRIX 6.5 (was Re: Re: Call for platforms)

Peter Eisentraut <peter_e@gmx.net> — 2001-03-27T15:42:03Z

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/

Re: Re: Call for platforms

Mathijs Brands <mathijs@ilse.nl> — 2001-03-27T16:06:17Z

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

Re: Call for platforms

tih@kpnqwest.no — 2001-03-27T20:27:15Z

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.

Re: Re: Call for platforms

Tom Lane <tgl@sss.pgh.pa.us> — 2001-03-27T20:44:08Z

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

Re: Re: Call for platforms

thomas graichen <list-pgsql.hackers@spoiled.org> — 2001-03-27T21:00:40Z

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

Re: Re: Call for platforms

Tatsuo Ishii <t-ishii@sra.co.jp> — 2001-03-28T01:39:51Z

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

Re: Re: Call for platforms

segfault@hardline.org — 2001-03-28T01:49:24Z

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

Re: Re: Call for platforms

segfault@hardline.org — 2001-03-28T03:45:22Z

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

Re: Re: Call for platforms

segfault@hardline.org — 2001-03-28T03:45:22Z

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

Re: Re: Call for platforms

Tom Lane <tgl@sss.pgh.pa.us> — 2001-03-28T05:27:51Z

"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'
  };

Re: Re: Call for platforms

Tom Lane <tgl@sss.pgh.pa.us> — 2001-03-28T05:51:55Z

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

Re: Re: Call for platforms

Tatsuo Ishii <t-ishii@sra.co.jp> — 2001-03-28T05:53:35Z

> 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

Re: Re: Call for platforms

Tom Lane <tgl@sss.pgh.pa.us> — 2001-03-28T06:08:45Z

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

Re: Re: Call for platforms

Tatsuo Ishii <t-ishii@sra.co.jp> — 2001-03-28T06:11:59Z

> 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

Re: Re: Call for platforms

segfault@hardline.org — 2001-03-29T02:16:32Z

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?

Re: Re: Call for platforms

Tom Lane <tgl@sss.pgh.pa.us> — 2001-03-29T04:06:42Z

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

Re: Re: Call for platforms

segfault@hardline.org — 2001-03-30T03:33:42Z

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.

Re: Re: Call for platforms

Tom Lane <tgl@sss.pgh.pa.us> — 2001-03-30T04:58:25Z

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

Re: Call for platforms

Thomas Lockhart <lockhart@alumni.caltech.edu> — 2001-03-30T15:04:25Z

>  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

Re: Call for platforms

tih@kpnqwest.no — 2001-04-01T08:16:56Z

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.

Re: Re: Call for platforms

Tom Lane <tgl@sss.pgh.pa.us> — 2001-04-02T03:09:45Z

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

Re: Call for platforms

Thomas Lockhart <lockhart@alumni.caltech.edu> — 2001-04-02T06:49:53Z

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