Second call for platform testing

Thomas Lockhart wrote:

The following platforms have been reported as successfully running
PostgreSQL 7.2:

AIX Andreas Zeugswetter (Tatsuo working on 5L?)
BSD/OS Bruce
FreeBSD Chris Kings-Lynne
HPUX Tom (anyone tested 11.0 or higher?)

Are you still looking for HPUX 11.0+ ? I can arrange for access to one
if we still need it (gcc though, I don't have access to HP's compiler).

-- Joe

I just tested the BeOS port (and updated the regression test database).

Two little tweaks are needed to make it compile and install :

* int8/uint8 and int64/uint64 are not detected properly by configure
(they are declared in SupportDefs.h on beos).
* data dir is created with group and world access, preventing
postmaster from starting (a simple chmod og-rwx will do)

The regression test pass without any error.

cyril

Are you still looking for HPUX 11.0+ ? I can arrange for access to one
if we still need it (gcc though, I don't have access to HP's compiler).

Yes, that would be great. 10.20 is pretty old afaik...

- Thomas

I just tested the BeOS port (and updated the regression test database).
Two little tweaks are needed to make it compile and install :
* int8/uint8 and int64/uint64 are not detected properly by configure
(they are declared in SupportDefs.h on beos).
* data dir is created with group and world access, preventing
postmaster from starting (a simple chmod og-rwx will do)
The regression test pass without any error.

Great! Can the int8 detection be helped with a patch to get the right
include file?

- Thomas

SCO OpenUNIX should be Caldera OpenUNIX....

Thanks,
LER

* Thomas Lockhart <lockhart@fourpalms.org> [011128 22:07]:

OK, the list is getting smaller fast (thanks for all of the responses!).
Here is what I have left currently (note the addition of NetBSD/sparc,
which I had inadvertently omitted from the first list):

BeOS Cyril Velter
Linux/arm Mark Knox
Linux/s390 Neale Ferguson
NetBSD/arm32 Patrick Welche
NetBSD/m68k Bill Studenmund (will test)
NetBSD/sparc Matthew Green (left off the first list)
NetBSD/VAX Tom I. Helbekkmo
QNX (did I get a definitive report for 4.x already?)
SunOS Tatsuo Ishii (old release; still relevant?)
Windows/Cygwin Daniel Horak (OK in serial test, trouble with parallel
test?)
Windows/native Magnus Hagander (clients only)

I'm curious about the Windows/Cygwin trouble, and if others see it too,
since the -cygwin mailing list seems to report happiness with 7.1.3.

Tatsuo, do you think that we should still track SunOS explicitly?

Are there any other platforms we are running on?

- Thomas

The following platforms have been reported as successfully running
PostgreSQL 7.2:

AIX Andreas Zeugswetter (Tatsuo working on 5L?)
BSD/OS Bruce
FreeBSD Chris Kings-Lynne
HPUX Tom (anyone tested 11.0 or higher?)
IRIX Luis Amigo
Linux/Alpha Tom
Linux/MIPS Hisao Shibuya
Linux/PPC Tom
Linux/sparc Doug McNaught
Linux/x86 Thomas (and many others ;)
MacOS-X Gavin Sherry
NetBSD/Alpha Thomas Thai
NetBSD/PPC Bill Studenmund
NetBSD/x86 Bill Studenmund
OpenBSD/sparc Brandon Palmer
OpenBSD/x86 Brandon Palmer
SCO OpenUnix Larry Rosenman
Solaris/sparc Andrew Sullivan
Solaris/x86 Martin Renters
Tru64 Alessio Bragadini (trouble with 5.1?)

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

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

SCO OpenUNIX should be Caldera OpenUNIX....

Got it. Thanks.

- Thomas

I just tested the BeOS port (and updated the regression test

database).

Two little tweaks are needed to make it compile and install :
* int8/uint8 and int64/uint64 are not detected properly by

configure

(they are declared in SupportDefs.h on beos).
* data dir is created with group and world access, preventing
postmaster from starting (a simple chmod og-rwx will do)
The regression test pass without any error.

Great! Can the int8 detection be helped with a patch to get the right
include file?

I think it can, but I'm not familiar at all with configure script. If
someone can point me where the change should be made, I'll make and test a
patch.

What modification should be made to configure.in to make it include
SupportDefs.h when testing for int8 uint8 int64 and uint64 size ?

cyril

What modification should be made to configure.in to make it

include

SupportDefs.h when testing for int8 uint8 int64 and uint64 size ?

Is SupportDefs.h actually (probably implicitly) included by the
PostgreSQL
source ? Because if it is not, PostgreSQL is quite happy not finding
them in
configure.

Not finding them is only a problem if you get redefines during
compilation
(and if your compiler then treats that as fatal).

Andreas

What modification should be made to configure.in to make it

include

SupportDefs.h when testing for int8 uint8 int64 and uint64 size ?

Is SupportDefs.h actually (probably implicitly) included by the
PostgreSQL
source ? Because if it is not, PostgreSQL is quite happy not finding
them in
configure.

Not finding them is only a problem if you get redefines during
compilation
(and if your compiler then treats that as fatal).

Good point. Also, a mixed-case include file is quite unusual. One idea
if you can't get it working is to either include "SupportDefs.h" for
BeOS in configure.in and c.h, or check the top of SupportDefs.h. Often
there is an #ifdef at the top to prevent the file from being included
twice. If you define that in c.h for BeOS, the include SupportDefs.h
will never be used and we can use our own defines for uint8/uint64.

FYI, this test was added for AIX in recent weeks because it had similar
trouble.

Here is the little snippet of code from configure to test for uint8:

#include "confdefs.h"
#include <stdio.h>
main()
{
FILE *f=fopen("conftestval", "w");
if (!f) exit(1);
fprintf(f, "%d\n", sizeof(uint8));
exit(0);
}

Now, we would normally modify configure.in, but you can play with
configure until you get it to work, let us know, and we can modify
configure.in, run autoconf, make any needed additions to c.h, and get it
into CVS.

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

"Cyril VELTER" <cyril.velter@libertysurf.fr> writes:

What modification should be made to configure.in to make it include
SupportDefs.h when testing for int8 uint8 int64 and uint64 size ?

This looks like a bit of a pain. We're currently using AC_CHECK_SIZEOF
to make those probes, apparently because it's the closest standard macro
to what we want. But it's not close enough. It doesn't include
anything except <stdio.h>. I don't think we can fix this except by
making our own macro. Peter, any opinion about how to do it?

(If we do make our own macro, we could change the output to be something
more reasonable, like #defining HAVE_UINT8 rather than claiming
"sizeof uint8 = 0", which is sure to confuse people.)

regards, tom lane

What modification should be made to configure.in to make it include
SupportDefs.h when testing for int8 uint8 int64 and uint64 size ?

Is SupportDefs.h actually (probably implicitly) included by the
PostgreSQL
source ? Because if it is not, PostgreSQL is quite happy not finding
them in
configure.

Not finding them is only a problem if you get redefines during
compilation
(and if your compiler then treats that as fatal).

SupportDefs.h is conditionaly included in c.h so everything is Ok when I
compile the backend, but when configure try to figure out the size of int8
... they are not defined.

May be SupportDefs.h should be included from another file ?

cyril

Cyril VELTER writes:

I just tested the BeOS port (and updated the regression test database).

Two little tweaks are needed to make it compile and install :

* int8/uint8 and int64/uint64 are not detected properly by configure
(they are declared in SupportDefs.h on beos).

Well, that was the end of that bright idea. There's no way to tell
AC_CHECK_SIZEOF what header files to consider. We need to put back the
#ifdef __BEOS__, it seems.

* data dir is created with group and world access, preventing
postmaster from starting (a simple chmod og-rwx will do)

What does the shell do with the umask call in initdb?

--
Peter Eisentraut peter_e@gmx.net

"Cyril VELTER" <cyril.velter@libertysurf.fr> writes:

What modification should be made to configure.in to make it include
SupportDefs.h when testing for int8 uint8 int64 and uint64 size ?

This looks like a bit of a pain. We're currently using AC_CHECK_SIZEOF
to make those probes, apparently because it's the closest standard macro
to what we want. But it's not close enough. It doesn't include
anything except <stdio.h>. I don't think we can fix this except by
making our own macro. Peter, any opinion about how to do it?

I was wondering where that bizarre fopen()/fprintf() in the test code
came from. It looked strange. Now I know why; it came from autoconf.

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

* data dir is created with group and world access, preventing
postmaster from starting (a simple chmod og-rwx will do)

What does the shell do with the umask call in initdb?

I will look at it (I'm not on a beos box right now), but as BeOS is
not a true multiuser system, he is probably faulty here.

cyril

Thomas Lockhart wrote:

Are you still looking for HPUX 11.0+ ? I can arrange for access to one
if we still need it (gcc though, I don't have access to HP's compiler).

Yes, that would be great. 10.20 is pretty old afaik...

- Thomas

I ran into a problem on HPUX 11 right off with:

===============================
configure --enable-debug
.
.
.
checking for struct sockaddr_un... yes
checking for int timezone... yes
checking types of arguments for accept()... configure: error: could not
determine argument types

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

I won't pretend to be very knowledgable about HPUX or configure, but it
looks like the following in configure is where it dies:

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

else
for ac_cv_func_accept_arg1 in 'int' 'unsigned int'; do
for ac_cv_func_accept_arg2 in 'struct sockaddr *' 'const struct
sockaddr *' 'void *'; do
for ac_cv_func_accept_arg3 in 'int' 'size_t' 'socklen_t'
'unsigned int' 'void'; do
cat > conftest.$ac_ext <<EOF

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

and here's what the HPUX man page says:

=======================================
accept(2)

NAME
accept - accept a connection on a socket

SYNOPSIS
#include <sys/socket.h>

AF_CCITT only
#include <x25/x25addrstr.h>

int accept(int s, void *addr, int *addrlen);

_XOPEN_SOURCE_EXTENDED only (UNIX 98)
int accept(int s, struct sockaddr *addr, socklen_t *addrlen);

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

so it looks like configure expects the third argument to be (int), when
on HPUX 11 the third argument is (int *).

Any ideas what I'm doing wrong?

-- Joe

Joe Conway <joseph.conway@home.com> writes:

I ran into a problem on HPUX 11 right off with:

That's odd, considering that someone else reported 7.1 worked fine on
HPUX 11, and we haven't changed this configure test since then.

so it looks like configure expects the third argument to be (int), when
on HPUX 11 the third argument is (int *).

No, the macro knows that the third argument is pointer-to-something;
it's trying to figure out pointer-to-what.

Any ideas what I'm doing wrong?

What had configure selected so far for compiler, cflags, etc? Maybe
it's blowing the game at that stage. Or maybe the test is failing to
include all the needed include files to define these datatypes.

In general, the config.log output is a good thing to post when puzzled
by configure problems.

regards, tom lane

Tom Lane wrote:

What had configure selected so far for compiler, cflags, etc? Maybe
it's blowing the game at that stage. Or maybe the test is failing to
include all the needed include files to define these datatypes.

In general, the config.log output is a good thing to post when puzzled
by configure problems.

OK. Figured out a couple of pieces to this. First, although I was told
we did not have HP's compiler, it is actually there. Second, since gcc
was freshly installed, it wasn't in my PATH. So the error I reported
last time is actually from the bundled compiler.

So I added /opt/gcc/bin to my PATH, and got a different error once gcc
was detected.

Attached are both config.log files. Sorry for being so clueless here,
but I haven't done much on HPUX before.

Joe

Joe Conway <joseph.conway@home.com> writes:

... So the error I reported
last time is actually from the bundled compiler.

Which, unless HP has reconsidered since HPUX 10, is a deliberately
crippled K&R (no ANSI features) compiler. It's no wonder the configure
run failed; I guess failing right at this point is happenstance, though
it could not have gotten further since this test depends on ANSI
prototypes.

configure:1361: checking whether the C compiler (cc -Ae +O2 ) works
configure:1377: cc -Ae -o conftest +O2 conftest.c 1>&5
(Bundled) cc: warning 480: The -A option is available only with the C/ANSI C product; ignored.
(Bundled) cc: warning 480: The +O2 option is available only with the C/ANSI C product; ignored.

It's a shame configure hides all these useful messages down inside
config.log.

I wonder whether we shouldn't make the bare "does it work" test include
verification that ANSI-style prototypes are supported.

So I added /opt/gcc/bin to my PATH, and got a different error once gcc
was detected.

configure:1243: checking whether the C compiler (gcc ) works
configure:1259: gcc -o conftest conftest.c 1>&5
as: warning 2: Unknown option "--traditional-format" ignored.
as: "/var/tmp/cceTg0Kd.s", line 15: error 1052: Directive name not recognized - NSUBSPA

This looks like your gcc installation is broken: specifically, I'll bet
it's trying to use HP's assembler rather than gas. You really want the
GNU toolchain (binutils package) underneath gcc. The gcc-to-HP-as
configuration has never worked for me (though I have to admit I haven't
tried in a long time).

In the meantime, try it with HP's real compiler (set CC=cc for configure).

regards, tom lane

Thomas Lockhart wrote:

OK, the list is getting smaller fast (thanks for all of the responses!).

I got a regression test result from Hiroshi Saito on
UNIX_System_V ews4800 4.2MP 4.2 R4000 r4000.

=======================
10 of 79 tests failed.
========================

int8 ... FAILED
abstime ... FAILED
tinterval ... FAILED
test geometry ... FAILED
test horology ... FAILED
create_index ... FAILED
test sanity_check ... FAILED
test select ... FAILED
subselect ... FAILED
union ... FAILED

Seems INT64_IS_BUSTED, old PST ... etc and

*** ./expected/create_index.out	Tue Aug 28 08:23:34 JST 2001
--- ./results/create_index.out	Fri Nov 30 00:28:22 JST 2001
***************
*** 35,44 ****
--- 35,47 ----
  --
  CREATE INDEX onek2_u1_prtl ON onek2 USING btree(unique1 int4_ops)
  	where unique1 < 20 or unique1 > 980;
+ ERROR:  AllocSetFree: cannot find block containing chunk 4f64f0
  CREATE INDEX onek2_u2_prtl ON onek2 USING btree(unique2 int4_ops)
  	where stringu1 < 'B';
+ ERROR:  AllocSetFree: cannot find block containing chunk 4f6390
  CREATE INDEX onek2_stu1_prtl ON onek2 USING btree(stringu1 name_ops)
  	where onek2.stringu1 >= 'J' and onek2.stringu1 < 'K';
+ ERROR:  AllocSetFree: cannot find block containing chunk 4f6740
  --
  -- RTREE
  -- 

regards,
Hiroshi Inoue

Has someone thought about getting a sourceforge account for postgres or
something? Even if we don't use their CVS and facilities, I wonder if we
can use their compile farm for platform testing?

Actually, maybe the phpPgAdmin admins could test it for us on the compile
farm, as they should have access...

Chris

Hiroshi Inoue <Inoue@tpf.co.jp> writes:

I got a regression test result from Hiroshi Saito on
UNIX_System_V ews4800 4.2MP 4.2 R4000 r4000.

Seems INT64_IS_BUSTED, old PST ... etc and

*** ./expected/create_index.out	Tue Aug 28 08:23:34 JST 2001
--- ./results/create_index.out	Fri Nov 30 00:28:22 JST 2001
***************
*** 35,44 ****
--- 35,47 ----
--
CREATE INDEX onek2_u1_prtl ON onek2 USING btree(unique1 int4_ops)
where unique1 < 20 or unique1 > 980;
+ ERROR:  AllocSetFree: cannot find block containing chunk 4f64f0
CREATE INDEX onek2_u2_prtl ON onek2 USING btree(unique2 int4_ops)
where stringu1 < 'B';
+ ERROR:  AllocSetFree: cannot find block containing chunk 4f6390
CREATE INDEX onek2_stu1_prtl ON onek2 USING btree(stringu1 name_ops)
where onek2.stringu1 >= 'J' and onek2.stringu1 < 'K';
+ ERROR:  AllocSetFree: cannot find block containing chunk 4f6740

Interesting. Something nonportable in the partial index support,
perhaps?

Would you ask him to compile with debug support, set a breakpoint at
elog(), and get a backtrace from the point of the error? It'll probably
work to execute any one of those commands by hand in the regression
database, so he doesn't need to try to attach to a regression testing
backend on the fly. Just start psql, attach gdb to its backend, set the
breakpoint, and then run the create index command.

regards, tom lane

"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:

Has someone thought about getting a sourceforge account for postgres or
something? Even if we don't use their CVS and facilities, I wonder if we
can use their compile farm for platform testing?

Hardly need a project account. I have a personal account at
sourceforge, and have used it (fairly recently, even) to run tests on
their compile farm. They don't presently have all that wide a range of
stuff available however. Let's see ....

lqqqqqqqqChoose compile farm server...qqqqqqqqqk
x A. [x86] Linux 2.2 (Debian 2.2) x
x C. [x86] FreeBSD (4.3-RELEASE) x
x x
x G. [Alpha] Linux 2.2 (Debian 2.2) x
x x
x I. [PPC - G4] MacOS X 10.1 #1 **NEW** x
x J. [PPC - G4] MacOS X 10.1 #2 **NEW** x
x K. [PPC - RS/6000] Linux 2.2 (Debian 2.2) x
x x
x L. [Sparc - Ultra60] Linux 2.2 (Debian 2.2) x
x M. [Sparc - R220] Sun Solaris (8) #1 x
x N. [Sparc - R220] Sun Solaris (8) #2 x
x O. [Sparc - R220] Sun Solaris (8) #3 x
x P. [Sparc - R220] Sun Solaris (8) #4 x
x x
x Exit x
mqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqj

With the possible exception of the Linux/Alpha box, there's nothing
there that we don't have covered already, is there?

regards, tom lane

Fair enough.

Chris

Tom Lane wrote:

configure:1243: checking whether the C compiler (gcc ) works
configure:1259: gcc -o conftest conftest.c 1>&5
as: warning 2: Unknown option "--traditional-format" ignored.
as: "/var/tmp/cceTg0Kd.s", line 15: error 1052: Directive name not recognized - NSUBSPA

This looks like your gcc installation is broken: specifically, I'll bet
it's trying to use HP's assembler rather than gas. You really want the
GNU toolchain (binutils package) underneath gcc. The gcc-to-HP-as
configuration has never worked for me (though I have to admit I haven't
tried in a long time).

In the meantime, try it with HP's real compiler (set CC=cc for configure).

As usual Tom, you're right on the mark!

The HP compiler on this machine is in fact the K&R/non-ANSI bundled
compiler. Unfortunately, the real compiler is not available -- i.e. we
have not purchased it.

I did get binutils installed though, and was able to run configure and
gmake. However, 'gmake check' seems to hang at:

parallel group (20 tests): lseg point

I have a copy of gdb which has not been installed yet. Tomorrow I'll ask
our unix admin to install it for me so I can drill down to the problem
code. Any other thoughts in the meantime?

FWIW, the server is a new A Class HP:
$ uname -a
HP-UX csdoap2 B.11.00 A 9000/800 594720518 two-user license

Thanks,

Joe

Joe Conway <joseph.conway@home.com> writes:

I did get binutils installed though, and was able to run configure and
gmake. However, 'gmake check' seems to hang at:

parallel group (20 tests): lseg point

That one's in the FAQ ;-). Evidently HP still hasn't fixed that sh bug
as of 11.0. Should work if you use ksh instead, viz

gmake SHELL=/bin/ksh check

regards, tom lane

Tom Lane wrote:

That one's in the FAQ ;-). Evidently HP still hasn't fixed that sh bug
as of 11.0. Should work if you use ksh instead, viz

gmake SHELL=/bin/ksh check

Correct again (not that I ever doubted you)! Sorry, I should have known
to look at the platform FAQ.

And after all that, the results:

====================================================
2 of 79 tests failed, 1 of these failures ignored.
====================================================

geometry and random failed. The diffs are attached. The geometry diffs
all look to be 0 vs -0.

Again, for reference:
$ model
9000/800/A500-44
$ uname -a
HP-UX csdoap2 B.11.00 A 9000/800

Joe

...

geometry and random failed. The diffs are attached. The geometry diffs
all look to be 0 vs -0.
$ model
9000/800/A500-44
$ uname -a
HP-UX csdoap2 B.11.00 A 9000/800

Great! Thanks for testing; I'll update the list...

- Thomas

Joe Conway <joseph.conway@home.com> writes:

geometry and random failed. The diffs are attached. The geometry diffs
all look to be 0 vs -0.

Okay, it looks like HP has implemented -0 finally. Try the other
geometry comparison files to see if any match;
geometry-positive-zeros.out is evidently only good for HPUX 10.

regards, tom lane

Tom Lane wrote:

Okay, it looks like HP has implemented -0 finally. Try the other
geometry comparison files to see if any match;
geometry-positive-zeros.out is evidently only good for HPUX 10.

A little experimentation shows that "geometry-solaris-precision.out" is
a perfect match. Two questions:

1. Do we use "geometry-solaris-precision.out", or clone it with a more
appropriate name like "geometry-hpux11.out" or
"geometry-hpux-precision.out"?

2. The current resultmap says: "geometry/hppa=geometry-positive-zeros".
What do we modify to so that it differentiates between HPUX11 and
HPUX10? I see it's related to the config.guess output and the pg_regress
script, but it's not clear to me where to make a change.

Joe

-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]

Hiroshi Inoue <Inoue@tpf.co.jp> writes:

I got a regression test result from Hiroshi Saito on
UNIX_System_V ews4800 4.2MP 4.2 R4000 r4000.

Seems INT64_IS_BUSTED, old PST ... etc and

*** ./expected/create_index.out	Tue Aug 28 08:23:34 JST 2001
--- ./results/create_index.out	Fri Nov 30 00:28:22 JST 2001
***************
*** 35,44 ****
--- 35,47 ----
--
CREATE INDEX onek2_u1_prtl ON onek2 USING btree(unique1 int4_ops)
where unique1 < 20 or unique1 > 980;
+ ERROR:  AllocSetFree: cannot find block containing chunk 4f64f0
CREATE INDEX onek2_u2_prtl ON onek2 USING btree(unique2 int4_ops)
where stringu1 < 'B';
+ ERROR:  AllocSetFree: cannot find block containing chunk 4f6390
CREATE INDEX onek2_stu1_prtl ON onek2 USING btree(stringu1 name_ops)
where onek2.stringu1 >= 'J' and onek2.stringu1 < 'K';
+ ERROR:  AllocSetFree: cannot find block containing chunk 4f6740

Interesting. Something nonportable in the partial index support,
perhaps?

Would you ask him to compile with debug support, set a breakpoint at
elog(), and get a backtrace from the point of the error?

Unfortunately he doesn't seem to be able to do it at once
though he would like to do it. If he is ready he may reply
to this thread directly.

regards,
Hiroshi Inoue

Joe Conway <joseph.conway@home.com> writes:

A little experimentation shows that "geometry-solaris-precision.out" is
a perfect match. Two questions:

Excellent.

1. Do we use "geometry-solaris-precision.out", or clone it with a more
appropriate name like "geometry-hpux11.out" or
"geometry-hpux-precision.out"?

I'd use it as-is. Not worth the trouble to rename it, and we definitely
don't want to carry around two copies.

2. The current resultmap says: "geometry/hppa=geometry-positive-zeros".
What do we modify to so that it differentiates between HPUX11 and
HPUX10? I see it's related to the config.guess output and the pg_regress
script, but it's not clear to me where to make a change.

Looks like it's got to be

geometry/hppa-hp-hpux9=geometry-positive-zeros
geometry/hppa-hp-hpux10=geometry-positive-zeros
geometry/hppa-hp-hpux11=geometry-solaris-precision

Ugh, but ...

Please check that's OK on 11, and I'll double check it on 10.

regards, tom lane

Tom Lane wrote:

Looks like it's got to be

geometry/hppa-hp-hpux9=geometry-positive-zeros
geometry/hppa-hp-hpux10=geometry-positive-zeros
geometry/hppa-hp-hpux11=geometry-solaris-precision

Ugh, but ...

Please check that's OK on 11, and I'll double check it on 10.

I get:

test geometry ... FAILED
test horology ... trouble
============== shutting down postmaster ==============

=======================
1 of 37 tests failed.
=======================

Looks like geometry.out gets used.

Tried again with:
geometry/hppa2.0w-hp-hpux11.00=geometry-solaris-precision

and get:

======================
All 79 tests passed.
======================

So maybe it should be:
geometry/hppa.*-hp-hpux11.*=geometry-solaris-precision

yup:
======================
All 79 tests passed.
======================

Do you want a patch?

Joe

Joe Conway <joseph.conway@home.com> writes:

So maybe it should be:
geometry/hppa.*-hp-hpux11.*=geometry-solaris-precision

Mmm, probably so.

Do you want a patch?

I can take it from here. Thanks!

regards, tom lane

OK, the list is getting smaller fast (thanks for all of the responses!).
Here is what I have left currently (note the addition of NetBSD/sparc,
which I had inadvertently omitted from the first list):

BeOS Cyril Velter
Linux/arm Mark Knox
Linux/s390 Neale Ferguson
NetBSD/arm32 Patrick Welche
NetBSD/m68k Bill Studenmund (will test)
NetBSD/sparc Matthew Green (left off the first list)
NetBSD/VAX Tom I. Helbekkmo
QNX (did I get a definitive report for 4.x already?)
SunOS Tatsuo Ishii (old release; still relevant?)

I tried 7.2b3 on SunOS 4.1.4 with gcc 2.7.1. It gives a comile error:

gcc -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../../src/include
-c pmsignal.c -o pmsignal.o
pmsignal.c:38: parse error before `*'
pmsignal.c:38: warning: data definition has no type or storage class
pmsignal.c: In function `PMSignalInit':
pmsignal.c:47: `sig_atomic_t' undeclared (first use this function)
pmsignal.c:47: (Each undeclared identifier is reported only once
pmsignal.c:47: for each function it appears in.)
pmsignal.c:47: parse error before `)'
--
Tatsuo Ishii

Tatsuo Ishii <t-ishii@sra.co.jp> writes:

I tried 7.2b3 on SunOS 4.1.4 with gcc 2.7.1. It gives a comile error:

pmsignal.c:47: `sig_atomic_t' undeclared (first use this function)

sig_atomic_t is required by ANSI C to be declared in <signal.h>.
Is it declared anywhere in the SunOS system headers?

I suppose we could create a configure test that detects this,
but I wonder how long we want to go on supporting platforms whose
headers aren't even minimally ANSI-compliant.

regards, tom lane

Linux/arm Mark Knox

Had a look at 7.2b3 and sadly it's failing several tests. I saw several
"ERROR: PGSTAT: Creation of DB hash table failed" which I haven't seen before.

Geometry fails as usual due to some minor rounding. The others are
completely wrong. I'm afraid I don't have much time to look at this right
now (sorry) but I've attached the regression output and diffs if anyone
wants to check them.

(Note: any responses should probably be addressed to me directly as well as
to the list.. I will likely miss them otherwise. Thanks.)

__ .--------.
|==|| | -( Mark 'segfault' Knox )-
|==||________|
|::| __====__`. .'`. "Unix *is* user-friendly.. it's just
|__|/::::::::\ ~ (_) picky about its friends."

Tom Lane writes:

"Cyril VELTER" <cyril.velter@libertysurf.fr> writes:

What modification should be made to configure.in to make it include
SupportDefs.h when testing for int8 uint8 int64 and uint64 size ?

This looks like a bit of a pain. We're currently using AC_CHECK_SIZEOF
to make those probes, apparently because it's the closest standard macro
to what we want. But it's not close enough. It doesn't include
anything except <stdio.h>. I don't think we can fix this except by
making our own macro. Peter, any opinion about how to do it?

OK, I bit the bullet and made up a whole new macro for type testing.
Those who can't get at a new snapshot can try the attached patch.

I have included <stdio.h> because that appears to effect the definition of
the types in question on AIX; apparently it pulls in <inttypes.h> somehow.

Please check this on AIX and BeOS.

--
Peter Eisentraut peter_e@gmx.net

NetBSD/sparc Matthew Green (left off the first list)

`gmake check' gets:

======================
All 79 tests passed.
======================

on both netbsd/sparc & netbsd/sparc64.

.mrg.

What modification should be made to configure.in to make it

include

SupportDefs.h when testing for int8 uint8 int64 and uint64 size ?

OK, I bit the bullet and made up a whole new macro for type testing.
Those who can't get at a new snapshot can try the attached patch.

I have included <stdio.h> because that appears to effect the

definition of

the types in question on AIX; apparently it pulls in <inttypes.h>

somehow.

Correct. stdio.h pulls sys/types.h which then pulls sys/inttypes.h ==
inttypes.h.

Please check this on AIX and BeOS.

Works like a charm on AIX :-) (Tested snapshot of 3 Dec 4:01)
I think it is also a gain, since it does not confuse people looking at
configure output.

Thank you Peter
Andreas

`gmake check' gets:
All 79 tests passed.
on both netbsd/sparc & netbsd/sparc64.

Great. Thanks!

- Thomas

Linux/arm Mark Knox

Had a look at 7.2b3 and sadly it's failing several tests. I saw several
"ERROR: PGSTAT: Creation of DB hash table failed" which I haven't seen before.
Geometry fails as usual due to some minor rounding. The others are
completely wrong. I'm afraid I don't have much time to look at this right
now (sorry) but I've attached the regression output and diffs if anyone
wants to check them.

Most (or at least some; didn't count them up) of these look like
ordering differences on results which are not guaranteed to be ordered,
so are OK.

The DB hash table trouble looks significant, but I don't know about that
area of the code.

Anyone?

- Thomas

Tatsuo Ishii <t-ishii@sra.co.jp> writes:

I tried 7.2b3 on SunOS 4.1.4 with gcc 2.7.1. It gives a comile error:

I've added a configure test for sig_atomic_t, if you want to try again
with CVS tip.

regards, tom lane

Mark Knox <segfault@hardline.org> writes:

Had a look at 7.2b3 and sadly it's failing several tests. I saw several
"ERROR: PGSTAT: Creation of DB hash table failed" which I haven't seen before.

Ugh. If you don't have time to dig into that, can you provide a login
on your machine for someone else to look at it?

regards, tom lane

Mark Knox <segfault@hardline.org> writes:

Had a look at 7.2b3 and sadly it's failing several tests. I saw several
"ERROR: PGSTAT: Creation of DB hash table failed" which I haven't seen before.

That error is coming from the following ugly coding:

*dbhash = hash_create("Databases hash", PGSTAT_DB_HASH_SIZE, &hash_ctl,
HASH_ELEM | HASH_FUNCTION | mcxt_flags);
if (pgStatDBHash == NULL)
/* raise error */

AFAICT dbhash always points at the static variable pgStatDBHash, so the
code is not quite incorrect, though it's certainly trouble waiting to
happen as soon as someone changes things so that dbhash might point
elsewhere. What I'm wondering is if your compiler is missing the
potential for aliasing and is emitting code that loads pgStatDBHash
before the store through dbhash occurs. Does it help if you change
the second line (line 2094 in src/backend/postmaster/pgstat.c) to:

if (*dbhash == NULL)

I'm going to commit this change in CVS anyway, but I'm wondering if it
explains your problem or not.

regards, tom lane

On Mon, Dec 03, 2001 at 02:01:30PM -0500, Tom Lane wrote:

That error is coming from the following ugly coding:

*dbhash = hash_create("Databases hash", PGSTAT_DB_HASH_SIZE, &hash_ctl,
HASH_ELEM | HASH_FUNCTION | mcxt_flags);
if (pgStatDBHash == NULL)
/* raise error */

Interesting...

AFAICT dbhash always points at the static variable pgStatDBHash, so the
code is not quite incorrect, though it's certainly trouble waiting to
happen as soon as someone changes things so that dbhash might point
elsewhere. What I'm wondering is if your compiler is missing the

Possibly.. it's not the most recent by any means, but it generally behaves
well. Unfortunately, nobody is maintaining the arm gcc toolchain anymore (as
far as I know).

before the store through dbhash occurs. Does it help if you change
the second line (line 2094 in src/backend/postmaster/pgstat.c) to:

if (*dbhash == NULL)

I'm going to commit this change in CVS anyway, but I'm wondering if it
explains your problem or not.

I'll give it a shot later tonight and let you know. Thanks for having a
look.

--
__ .--------.
|==|| | -( Mark 'segfault' Knox )-
|==||________|
|::| __====__`. .'`. "Unix *is* user-friendly.. it's just
|__|/::::::::\ ~ (_) picky about its friends."

Tatsuo Ishii <t-ishii@sra.co.jp> writes:

I tried 7.2b3 on SunOS 4.1.4 with gcc 2.7.1. It gives a comile error:

I've added a configure test for sig_atomic_t, if you want to try again
with CVS tip.

Thanks. But compiling fails again:

formatting.c: In function `NUM_processor':
formatting.c:4143: invalid operands to binary +
formatting.c:4153: invalid operands to binary +
formatting.c: In function `float4_to_char':
formatting.c:4667: warning: assignment makes integer from pointer without a cast
formatting.c: In function `float8_to_char':
formatting.c:4746: warning: assignment makes integer from pointer without a cast
gmake[4]: *** [formatting.o] Error 1
gmake[4]: Leaving directory `/mnt2/tmp/pgsql/src/backend/utils/adt'
gmake[3]: *** [adt-recursive] Error 2
gmake[3]: Leaving directory `/mnt2/tmp/pgsql/src/backend/utils'
gmake[2]: *** [utils-recursive] Error 2
gmake[2]: Leaving directory `/mnt2/tmp/pgsql/src/backend'
gmake[1]: *** [all] Error 2
gmake[1]: Leaving directory `/mnt2/tmp/pgsql/src'
gmake: *** [all] Error 2

It seems the code assumes sprintf always returns an integer (this is
not true for SunOS). I will fix it in more portable way.
--
Tatsuo Ishii

On Tue, Dec 04, 2001 at 03:15:58PM +0900, Tatsuo Ishii wrote:

It seems the code assumes sprintf always returns an integer (this is
not true for SunOS). I will fix it in more portable way.

It's interesting OS :-) I see "CONFORMING TO" part of sprintf manual
and it's ANSI C and ISO/IEC function....

Is anywhere (URL) summary of difference between basic C functions in
basic OS?

Thanks for fix Tatsuo.

Karel
--
Karel Zak <zakkr@zf.jcu.cz>
http://home.zf.jcu.cz/~zakkr/

C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz

What modification should be made to configure.in to make it

include

SupportDefs.h when testing for int8 uint8 int64 and uint64 size ?

OK, I bit the bullet and made up a whole new macro for type testing.
Those who can't get at a new snapshot can try the attached patch.

I have included <stdio.h> because that appears to effect the

definition of

the types in question on AIX; apparently it pulls in <inttypes.h>

somehow.

Correct. stdio.h pulls sys/types.h which then pulls sys/inttypes.h ==
inttypes.h.

Please check this on AIX and BeOS.

The detection now works on BEOS

thanks

cyril

Hiroshi Inoue wrote:

-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]

Hiroshi Inoue <Inoue@tpf.co.jp> writes:

I got a regression test result from Hiroshi Saito on
UNIX_System_V ews4800 4.2MP 4.2 R4000 r4000.

Seems INT64_IS_BUSTED, old PST ... etc and

*** ./expected/create_index.out     Tue Aug 28 08:23:34 JST 2001
--- ./results/create_index.out      Fri Nov 30 00:28:22 JST 2001
***************
*** 35,44 ****
--- 35,47 ----
--
CREATE INDEX onek2_u1_prtl ON onek2 USING btree(unique1 int4_ops)
where unique1 < 20 or unique1 > 980;
+ ERROR:  AllocSetFree: cannot find block containing chunk 4f64f0
CREATE INDEX onek2_u2_prtl ON onek2 USING btree(unique2 int4_ops)
where stringu1 < 'B';
+ ERROR:  AllocSetFree: cannot find block containing chunk 4f6390
CREATE INDEX onek2_stu1_prtl ON onek2 USING btree(stringu1 name_ops)
where onek2.stringu1 >= 'J' and onek2.stringu1 < 'K';
+ ERROR:  AllocSetFree: cannot find block containing chunk 4f6740

Interesting. Something nonportable in the partial index support,
perhaps?

Would you ask him to compile with debug support, set a breakpoint at
elog(), and get a backtrace from the point of the error?

Unfortunately he doesn't seem to be able to do it at once
though he would like to do it. If he is ready he may reply
to this thread directly.

Sorry for my late answer.
He has been working with the platform but hasn't yet
identify the cause. Unfortunately it seems too late
for 7.2 release.

regards,
Hiroshi Inoue

Hiroshi Inoue <Inoue@tpf.co.jp> writes:

He has been working with the platform but hasn't yet
identify the cause. Unfortunately it seems too late
for 7.2 release.

Not necessarily ... we're still arguing what to do about the time
precision issue, and even if 7.2fc1 were out, I think a portability bug
would be cause for an update. Please encourage him to pursue it.

regards, tom lane

change
the second line (line 2094 in src/backend/postmaster/pgstat.c) to:

if (*dbhash == NULL)

I'm going to commit this change in CVS anyway, but I'm wondering if it
explains your problem or not.

Yes it does, Tom! Nice work! I apologize for the delay in testing..
Christmas and all.

I guess I can report a success for 7.2b3 on Linux/arm.

__ .--------.
|==|| | -( Mark 'segfault' Knox )-
|==||________|
|::| __====__`. .'`. "Unix *is* user-friendly.. it's just
|__|/::::::::\ ~ (_) picky about its friends."

I'm going to commit this change in CVS anyway, but I'm wondering if it
explains your problem or not.

Yes it does, Tom! Nice work! I apologize for the delay in testing..
Christmas and all.

I guess I can report a success for 7.2b3 on Linux/arm.

I've just got hold of a FreeBSD/alpha box - hopefully I'll be able to test
by the end of the week...

Chris

I guess I can report a success for 7.2b3 on Linux/arm.

Great! Thanks for the work; I'll update the list...

- Thomas