Thread: 7.2beta3 on Digital Alpha
Just donwloaded and built 7.2beta3 on Compaq Tru64 (Digital Unix) 4.0 on Alpha architecture and now all regression tests are passed. test=# SELECT version(); version ----------------------------------------------------------------PostgreSQL 7.2b3 on alphaev67-dec-osf4.0g, compiled by cc-std -- Alessio F. Bragadini alessio@albourne.com APL Financial Services http://village.albourne.com Nicosia, Cyprus phone: +357-22-755750 "It is more complicated than you think" -- The Eighth Networking Truth from RFC 1925
> Just donwloaded and built 7.2beta3 on Compaq Tru64 (Digital Unix) 4.0 on
> Alpha architecture and now all regression tests are passed.
Thanks! Has anyone tested on more recent versions of Tru64 (I'm sure
they will work) and/or with gcc on this platform? We had reports
covering 4.0, 5.0, and two compilers for the previous release...
- Thomas
Thomas Lockhart wrote: > Thanks! Has anyone tested on more recent versions of Tru64 (I'm sure > they will work) and/or with gcc on this platform? We had reports > covering 4.0, 5.0, and two compilers for the previous release... All regression tests passed also with gcc version 2.95.1 19990816 (release) on alphaev67-dec-osf4.0g -- Alessio F. Bragadini alessio@albourne.com APL Financial Services http://village.albourne.com Nicosia, Cyprus phone: +357-22-755750 "It is more complicated than you think" -- The Eighth Networking Truth from RFC 1925
> All regression tests passed also with gcc version 2.95.1 19990816
> (release) on alphaev67-dec-osf4.0g
Thanks. I'll note both compilers...
- Thomas
Just tried on Tru64 5.1 using the Compaq C compiler. Failed the float8,
oidjoin and random tests.
*** ./expected/float8-fp-exception.out Thu Mar 30 02:46:00 2000
--- ./results/float8.out Wed Nov 28 19:29:33 2001
***************
*** 237,243 **** -- test for over- and underflow INSERT INTO FLOAT8_TBL(f1) VALUES ('10e400');
! ERROR: Input '10e400' is out of range for float8 INSERT INTO FLOAT8_TBL(f1) VALUES ('-10e400'); ERROR: Input
'-10e400'is out of range for float8 INSERT INTO FLOAT8_TBL(f1) VALUES ('10e-400');
--- 237,243 ---- -- test for over- and underflow INSERT INTO FLOAT8_TBL(f1) VALUES ('10e400');
! ERROR: Bad float8 input format '10e400' INSERT INTO FLOAT8_TBL(f1) VALUES ('-10e400'); ERROR: Input '-10e400' is
outof range for float8 INSERT INTO FLOAT8_TBL(f1) VALUES ('10e-400');
OIDJOIN had this...
! psql: server closed the connection unexpectedly
! This probably means the server terminated abnormally
! before or while processing the request.
--- ./results/random.out Wed Nov 28 19:33:03 2001
***************
*** 25,31 **** GROUP BY random HAVING count(random) > 1; random | count --------+-------
! (0 rows) SELECT random FROM RANDOM_TBL WHERE random NOT BETWEEN 80 AND 120;
--- 25,32 ---- GROUP BY random HAVING count(random) > 1; random | count --------+-------
! 119 | 2
! (1 row) SELECT random FROM RANDOM_TBL WHERE random NOT BETWEEN 80 AND 120;
======================================================================
I can post the whole regression.out file if someone needs it.
Jim
> Just donwloaded and built 7.2beta3 on Compaq Tru64 (Digital Unix) 4.0
on
> Alpha architecture and now all regression tests are passed.
>
> test=# SELECT version();
> version
> ----------------------------------------------------------------
> PostgreSQL 7.2b3 on alphaev67-dec-osf4.0g, compiled by cc -std
>
> --
> Alessio F. Bragadini alessio@albourne.com
> APL Financial Services http://village.albourne.com
> Nicosia, Cyprus phone: +357-22-755750
>
> "It is more complicated than you think"
> -- The Eighth Networking Truth from RFC 1925
>
> ---------------------------(end of
broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>
>
Thomas, see my replace to the original email. Tru64 5.1 fails float8, oidjoin and random... Jim > > Just donwloaded and built 7.2beta3 on Compaq Tru64 (Digital Unix) 4.0 on > > Alpha architecture and now all regression tests are passed. > > Thanks! Has anyone tested on more recent versions of Tru64 (I'm sure > they will work) and/or with gcc on this platform? We had reports > covering 4.0, 5.0, and two compilers for the previous release... > > - 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 > >
> Just tried on Tru64 5.1 using the Compaq C compiler. Failed the float8,
> oidjoin and random tests.
The float8 is certainly OK.
The random test fails, uh, randomly, should succeed sometimes on your
platform, so is probably OK if you try again.
But the oidjoin test is certainly broken. What optimization are you
compiling with? Does it work better if you turn optimization off??
- Thomas
NetBSD used to fail on these tests too, until they implemented soft-float.
On Wed, 28 Nov 2001, Jim Buttafuoco wrote:
> Date: Wed, 28 Nov 2001 20:35:04 -0500
> From: Jim Buttafuoco <jim@buttafuoco.net>
> To: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] 7.2beta3 on Digital Alpha
>
> Just tried on Tru64 5.1 using the Compaq C compiler. Failed the float8,
> oidjoin and random tests.
>
> *** ./expected/float8-fp-exception.out Thu Mar 30 02:46:00 2000
> --- ./results/float8.out Wed Nov 28 19:29:33 2001
> ***************
> *** 237,243 ****
>
> -- test for over- and underflow
> INSERT INTO FLOAT8_TBL(f1) VALUES ('10e400');
> ! ERROR: Input '10e400' is out of range for float8
> INSERT INTO FLOAT8_TBL(f1) VALUES ('-10e400');
> ERROR: Input '-10e400' is out of range for float8
> INSERT INTO FLOAT8_TBL(f1) VALUES ('10e-400');
> --- 237,243 ----
>
> -- test for over- and underflow
> INSERT INTO FLOAT8_TBL(f1) VALUES ('10e400');
> ! ERROR: Bad float8 input format '10e400'
> INSERT INTO FLOAT8_TBL(f1) VALUES ('-10e400');
> ERROR: Input '-10e400' is out of range for float8
> INSERT INTO FLOAT8_TBL(f1) VALUES ('10e-400');
>
> OIDJOIN had this...
> ! psql: server closed the connection unexpectedly
> ! This probably means the server terminated abnormally
> ! before or while processing the request.
>
> --- ./results/random.out Wed Nov 28 19:33:03 2001
> ***************
> *** 25,31 ****
> GROUP BY random HAVING count(random) > 1;
> random | count
> --------+-------
> ! (0 rows)
>
> SELECT random FROM RANDOM_TBL
> WHERE random NOT BETWEEN 80 AND 120;
> --- 25,32 ----
> GROUP BY random HAVING count(random) > 1;
> random | count
> --------+-------
> ! 119 | 2
> ! (1 row)
>
> SELECT random FROM RANDOM_TBL
> WHERE random NOT BETWEEN 80 AND 120;
>
> ======================================================================
>
>
>
>
> I can post the whole regression.out file if someone needs it.
>
> Jim
>
>
>
>
> > Just donwloaded and built 7.2beta3 on Compaq Tru64 (Digital Unix) 4.0
> on
> > Alpha architecture and now all regression tests are passed.
> >
> > test=# SELECT version();
> > version
> > ----------------------------------------------------------------
> > PostgreSQL 7.2b3 on alphaev67-dec-osf4.0g, compiled by cc -std
> >
> > --
> > Alessio F. Bragadini alessio@albourne.com
> > APL Financial Services http://village.albourne.com
> > Nicosia, Cyprus phone: +357-22-755750
> >
> > "It is more complicated than you think"
> > -- The Eighth Networking Truth from RFC 1925
> >
> > ---------------------------(end of
> broadcast)---------------------------
> > TIP 6: Have you searched our list archives?
> >
> > http://archives.postgresql.org
> >
> >
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>
"Jim Buttafuoco" <jim@buttafuoco.net> writes:
> OIDJOIN had this...
> ! psql: server closed the connection unexpectedly
> ! This probably means the server terminated abnormally
> ! before or while processing the request.
This is bad. There should be a core dump file --- can you provide
a debugger backtrace from it?
regards, tom lane
will do and report... > "Jim Buttafuoco" <jim@buttafuoco.net> writes: > > OIDJOIN had this... > > ! psql: server closed the connection unexpectedly > > ! This probably means the server terminated abnormally > > ! before or while processing the request. > > This is bad. There should be a core dump file --- can you provide > a debugger backtrace from it? > > regards, tom lane > >
I used the default configuration. just did a ./configure && gmake && gmake check > > Just tried on Tru64 5.1 using the Compaq C compiler. Failed the float8, > > oidjoin and random tests. > > The float8 is certainly OK. > > The random test fails, uh, randomly, should succeed sometimes on your > platform, so is probably OK if you try again. > > But the oidjoin test is certainly broken. What optimization are you > compiling with? Does it work better if you turn optimization off?? > > - Thomas > >
my error, the workstation I was compiling on had max_proc_per_user set to 64. Changed to 1024 and now just float8 and random fail. It looks like these errors are ok Jim > will do and report... > > > "Jim Buttafuoco" <jim@buttafuoco.net> writes: > > > OIDJOIN had this... > > > ! psql: server closed the connection unexpectedly > > > ! This probably means the server terminated abnormally > > > ! before or while processing the request. > > > > This is bad. There should be a core dump file --- can you provide > > a debugger backtrace from it? > > > > regards, tom lane > > > > > > >
"Jim Buttafuoco" <jim@buttafuoco.net> writes:
> my error, the workstation I was compiling on had max_proc_per_user set
> to 64.
Ah-hah. We probably ought to document that as a possible source of
failure in the parallel regression tests. I think the present script
will start as many as 20 parallel tests, which means 60 parallel
processes under your userid (a backend, a psql, and probably an owning
shell process for each psql). Add in the postmaster, your own shell,
a couple random make subprocesses, and you got trouble.
> Changed to 1024 and now just float8 and random fail. It looks
> like these errors are ok
You should find that random fails only, um, randomly. If it fails
every time then there's a problem.
regards, tom lane