RC1?

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Are we ready for RC1 yet?

I think so. The NO_MKTIME_BEFORE_1970 issue was bothering me, but I
feel that's resolved now. (It'd be nice to hear a crosscheck from
some AIX users though...)

regards, tom lane

On Tue, 12 Nov 2002, Bruce Momjian wrote:

Are we ready for RC1 yet?

This is Tuesday, you can only ask on Fridays :)

Vince.
--
http://www.meanstreamradio.com http://www.unknown-artists.com
Internet radio: It's not file sharing, it's just radio.

Are we ready for RC1 yet?

I'm waiting for jenny wang confirms the fix regarding GB18030
support. In the mean time, I'll commit the fix anyway since current
GB183030 support is so badly broken (I have checked all regression
tests have passed).
--
Tatsuo Ishii

'K, looks like we need two things confirmed ... the change that Tom made
concerning mktime(), which we need someone on AIX to test ... and the
following ...

I've been following the commit messages closely, and haven't seen anything
go in that make me edgy, so if we can get validation on those two, I think
we're good to go ...

On Tue, 12 Nov 2002, Tatsuo Ishii wrote:

Are we ready for RC1 yet?

I think so. The NO_MKTIME_BEFORE_1970 issue was bothering me, but I
feel that's resolved now. (It'd be nice to hear a crosscheck from
some AIX users though...)

abstime, tinterval and horology fail on AIX.
The rest is now working (AIX 4.3.2 xlc 5.0.0.2).

I am just now rebuilding with removing the #define NO_MKTIME_BEFORE_1970.
My feeling is, that there is no difference. Can that be ?
Attached are the regression diffs for vanilla 7.3b5

Andreas

"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at> writes:

abstime, tinterval and horology fail on AIX.=20

I would expect them now (without NO_MKTIME_BEFORE_1970) to match the
solaris-1947 comparison files for these tests. Could you confirm that?

regards, tom lane

I think so. The NO_MKTIME_BEFORE_1970 issue was bothering me, but I
feel that's resolved now. (It'd be nice to hear a crosscheck from
some AIX users though...)

abstime, tinterval and horology fail on AIX.
The rest is now working (AIX 4.3.2 xlc 5.0.0.2).

I am just now rebuilding with removing the #define NO_MKTIME_BEFORE_1970.

Ok, when #define NO_MKTIME_BEFORE_1970 is removed from aix.h, then the results
match the Solaris files.

Attached is a patch to make AIX match Solaris. Please apply and add AIX to
the supported platforms.

Thank you
Andreas

PS: what should we do with the rest of the resultmap entries for no-DST-before-1970 ?

"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at> writes:

Ok, when #define NO_MKTIME_BEFORE_1970 is removed from aix.h, then the
results match the Solaris files.

Great!

Attached is a patch to make AIX match Solaris. Please apply and add AIX
to the supported platforms.

Patch applied to 7.3 and CVS tip --- Bruce, you're maintaining the
supported-platforms list, right?

PS: what should we do with the rest of the resultmap entries for
no-DST-before-1970 ?

I can tell you that the hppa entry is correct. I presume the cygwin
folks would've mentioned it by now if theirs wasn't.

I suspect we are looking at two different behaviors for systems with no
old DST data: either assume all before 1970 is standard time (hppa does
this) or assume that years before 1970 use the same transition rule as
1970 (I'll bet that's what Solaris, AIX, etc are doing).

regards, tom lane

Tom Lane wrote:

"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at> writes:

Ok, when #define NO_MKTIME_BEFORE_1970 is removed from aix.h, then the
results match the Solaris files.

Great!

Attached is a patch to make AIX match Solaris. Please apply and add AIX
to the supported platforms.

Patch applied to 7.3 and CVS tip --- Bruce, you're maintaining the
supported-platforms list, right?

AIX updated in 7.3 and CVS.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian writes:

Are we ready for RC1 yet?

Questionable. We don't even have 50% confirmation coverage for the
supported platforms yet.

--
Peter Eisentraut peter_e@gmx.net

Peter Eisentraut <peter_e@gmx.net> writes:

Bruce Momjian writes:

Are we ready for RC1 yet?

Questionable. We don't even have 50% confirmation coverage for the
supported platforms yet.

We can't just wait around indefinitely for port reports that may or may
not ever appear. In any case, most of the "<7.3" entries in the list
seem to be various flavors of *BSD; I think it's unlikely we broke
those ...

regards, tom lane

On Tue, 2002-11-12 at 16:27, Tom Lane wrote:

Peter Eisentraut <peter_e@gmx.net> writes:

Bruce Momjian writes:

Are we ready for RC1 yet?

Questionable. We don't even have 50% confirmation coverage for the
supported platforms yet.

We can't just wait around indefinitely for port reports that may or may
not ever appear. In any case, most of the "<7.3" entries in the list
seem to be various flavors of *BSD; I think it's unlikely we broke
those ...

Why not send an email to the folks who last reported a supported
platform and ask for an update? Probably won't get through to everyone,
but it might help pare down the list of unconfirmed.

Robert Treat

On 12 Nov 2002, Robert Treat wrote:

On Tue, 2002-11-12 at 16:27, Tom Lane wrote:

Peter Eisentraut <peter_e@gmx.net> writes:

Bruce Momjian writes:

Are we ready for RC1 yet?

Questionable. We don't even have 50% confirmation coverage for the
supported platforms yet.

We can't just wait around indefinitely for port reports that may or may
not ever appear. In any case, most of the "<7.3" entries in the list
seem to be various flavors of *BSD; I think it's unlikely we broke
those ...

Why not send an email to the folks who last reported a supported
platform and ask for an update? Probably won't get through to everyone,
but it might help pare down the list of unconfirmed.

I'm testing x86 solaris right now. It's turning into a giant pain because
of how the box I'm on is configured.

On 12 Nov 2002, Robert Treat wrote:

On Tue, 2002-11-12 at 16:27, Tom Lane wrote:

Peter Eisentraut <peter_e@gmx.net> writes:

Bruce Momjian writes:

Are we ready for RC1 yet?

Questionable. We don't even have 50% confirmation coverage for the
supported platforms yet.

We can't just wait around indefinitely for port reports that may or may
not ever appear. In any case, most of the "<7.3" entries in the list
seem to be various flavors of *BSD; I think it's unlikely we broke
those ...

Why not send an email to the folks who last reported a supported
platform and ask for an update? Probably won't get through to everyone,
but it might help pare down the list of unconfirmed.

I get this for gmake check:

(Lotsa messages deleted):

============== removing existing temp installation ==============
============== creating temporary installation ==============
============== initializing database system ==============
============== starting postmaster ==============
running on port 65432 with pid 19771
============== creating database "regression" ==============
CREATE DATABASE
ALTER DATABASE
============== dropping regression test user accounts ==============
============== installing PL/pgSQL ==============
============== running regression test queries ==============
parallel group (13 tests): float4 int8 text int2 oid int4 char boolean
varchar name float8 bit numeric boolean ... ok
char ... ok
name ... ok
varchar ... ok
text ... ok
int2 ... ok
int4 ... ok
int8 ... ok
oid ... ok
float4 ... ok
float8 ... ok
bit ... ok
numeric ... ok
============== shutting down postmaster ==============

======================
All 13 tests passed.
======================

rm regress.o
gmake[2]: Leaving directory
`/home/smarlowe/postgresql-7.3b5/src/test/regress'
gmake[1]: Leaving directory `/home/smarlowe/postgresql-7.3b5/src/test'

(END QUOTE)

And then it stops. Anyone know why it doesn't run the rest of the
regresssion tests?

On Tue, 12 Nov 2002, Tom Lane wrote:

"scott.marlowe" <scott.marlowe@ihs.com> writes:

And then it stops. Anyone know why it doesn't run the rest of the
regresssion tests?

Somebody else just reported the same thing on Solaris. Must be
something about the pg_regress script that doesn't play nicely with
Solaris' shell. Can you poke into it and try to figure out what?
(Perhaps running the script with +x would help.)

will do.

On Tue, 12 Nov 2002, Tom Lane wrote:

"scott.marlowe" <scott.marlowe@ihs.com> writes:

And then it stops. Anyone know why it doesn't run the rest of the
regresssion tests?

Somebody else just reported the same thing on Solaris. Must be
something about the pg_regress script that doesn't play nicely with
Solaris' shell. Can you poke into it and try to figure out what?
(Perhaps running the script with +x would help.)

OK, make -x check fails, is there some other way to use -x I'm not
thinking of here?

"scott.marlowe" <scott.marlowe@ihs.com> writes:

And then it stops. Anyone know why it doesn't run the rest of the
regresssion tests?

Somebody else just reported the same thing on Solaris. Must be
something about the pg_regress script that doesn't play nicely with
Solaris' shell. Can you poke into it and try to figure out what?
(Perhaps running the script with +x would help.)

regards, tom lane

"scott.marlowe" <scott.marlowe@ihs.com> writes:

OK, make -x check fails, is there some other way to use -x I'm not
thinking of here?

I was thinking of running the script by hand, not via make:

/bin/sh -x ./pg_regress --temp-install --top-builddir=../../.. --schedule=./parallel_schedule --multibyte=SQL_ASCII

regards, tom lane

On Tue, 12 Nov 2002, Tom Lane wrote:

"scott.marlowe" <scott.marlowe@ihs.com> writes:

OK, make -x check fails, is there some other way to use -x I'm not
thinking of here?

I was thinking of running the script by hand, not via make:

/bin/sh -x ./pg_regress --temp-install --top-builddir=../../.. --schedule=./parallel_schedule --multibyte=SQL_ASCII

Ok, now that I've run it that way, the last couple of pages of output
look like this:

formatted=numeric
+ echo      numeric              ... \c
EXPECTED=./expected/numeric
     numeric              ... + expr abstime=abstime-solaris-1947 : 
numeric=
+ [ 0 -ne 0 ]
+ expr geometry=geometry-solaris-i386-pc : numeric=
+ [ 0 -ne 0 ]
+ expr horology=horology-solaris-1947 : numeric=
+ [ 0 -ne 0 ]
+ expr tinterval=tinterval-solaris-1947 : numeric=
+ [ 0 -ne 0 ]
bestfile=
bestdiff=
result=2
+ [ ! -r ./expected/numeric.out ]
+ diff -w ./expected/numeric.out ./results/numeric.out
result=0
+ break
+ echo ok
ok
+ read line
+ [ 0 -ne 0 ]
+ [ -n 22844 ]
+ message shutting down postmaster
_dashes===============
_spaces=
+ cut -c 1-38
+ echo shutting down postmaster
_msg=shutting down postmaster
+ echo ============== shutting down postmaster               
==============
============== shutting down postmaster               ==============
+ kill -15 22844
+ unset postmaster_pid
+ rm -f /tmp/pg_regress.19030
+ cat ./regression.out
+ grep \.\.\.
+ sed s/ //g
+ wc -l
count_total=13
+ cat ./regression.out
+ grep \.\.\. ok
+ + wc -l sed
 s/ //g
count_ok=13
+ cat ./regression.out
+ sed s/ //g
+ wc -l
+ grep \.\.\. FAILED
count_failed=0
+ cat ./regression.out
+ grep \.\.\. failed (ignored)
+ sed s/ //g
+ wc -l
count_ignored=0
+ echo

+ [ 13 -eq 13 ]
msg=All 13 tests passed.
result=0
+ sed s/./=/g
+ echo  All 13 tests passed.
dashes=======================
+ echo ======================
======================
+ echo  All 13 tests passed.
 All 13 tests passed.
+ echo ======================
======================
+ echo

+ [ -s ./regression.diffs ]
+ rm -f ./regression.diffs ./regression.out
+ exit 0
+ exit
savestatus=0
+ [ -n  ]
+ rm -f /tmp/pg_regress.19030
+ exit 0

Hope that helps.

"scott.marlowe" <scott.marlowe@ihs.com> writes:

Ok, now that I've run it that way, the last couple of pages of output
look like this:

Hm. So the "while read line" loop is iterating only once.

I was thinking to myself that something within the while loop must be
eating up stdin, so that there's nothing left for the "while read" to
read when control returns to the top of the loop. This strengthens that
theory. Now, exactly what is reading stdin?

My suspicion falls on the very-recently-added awk calls. Try changing

(echo "SET autocommit TO 'on';"; awk 'BEGIN {printf "\\set ECHO all\n"}'; cat "$inputdir/sql/$1.sql") |

to

(echo "SET autocommit TO 'on';"; awk 'BEGIN {printf "\\set ECHO all\n"}' </dev/null; cat "$inputdir/sql/$1.sql") |

(there are two places to do this)

regards, tom lane

On Tue, 12 Nov 2002, Tom Lane wrote:

Peter Eisentraut <peter_e@gmx.net> writes:

Bruce Momjian writes:

Are we ready for RC1 yet?

Questionable. We don't even have 50% confirmation coverage for the
supported platforms yet.

We can't just wait around indefinitely for port reports that may or may
not ever appear. In any case, most of the "<7.3" entries in the list
seem to be various flavors of *BSD; I think it's unlikely we broke
those ...

FWIW, gmake check and gmake bigcheck pass on:

FreeBSD 3.3-RELEASE #3: Thu Feb 3 23:48:56 GMT 2000

using:

gcc -v
gcc version 2.7.2.3

and

ld -v
GNU ld version 2.9.1 (with BFD 2.9.1)

with:

./configure --prefix=/usr/local/pgsql-7.2.1 --enable-multibyte --with-perl --with-tcl --enable-odbc --with-pam --enable-syslog --with-tclconfig=/usr/local/lib/tcl8.0 --with-tkconfig=/usr/local/lib/tk8.0 --with-includes=/usr/local/include/tcl8.0:/usr/local/include/tk8.0

with the expection of:

*** 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' ;

in the float8 test.

--
Nigel J. Andrews
Logictree Systems Limited

My suspicion falls on the very-recently-added awk calls. Try changing

(echo "SET autocommit TO 'on';"; awk 'BEGIN {printf
"\\set ECHO all\n"}'; cat "$inputdir/sql/$1.sql") |

Why use awk for this at all ? and not:
echo "\\set ECHO all"

??
Andreas

"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at> writes:

Why use awk for this at all ? and not:
echo "\\set ECHO all"

I think Bruce is worried about portability; some versions of echo might
do something weird with the backslash. OTOH, it's not obvious to me
that awk is better on that score. Bruce?

regards, tom lane

"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at> writes:

Why use awk for this at all ? and not:
echo "\\set ECHO all"

Actually, some googling revealed the following advice (in the Autoconf
manual):

Because of these problems, do not pass a string containing
arbitrary characters to echo. For example, echo "$foo" is safe if
you know that foo's value cannot contain backslashes and cannot
start with -, but otherwise you should use a here-document like
this:

cat <<EOF
$foo
EOF

This seems obviously safer, so I shall make it do that instead
of relying on either awk or echo.

regards, tom lane

On Tue, 12 Nov 2002, Tom Lane wrote:

"scott.marlowe" <scott.marlowe@ihs.com> writes:

Ok, now that I've run it that way, the last couple of pages of output
look like this:

Hm. So the "while read line" loop is iterating only once.

I was thinking to myself that something within the while loop must be
eating up stdin, so that there's nothing left for the "while read" to
read when control returns to the top of the loop. This strengthens that
theory. Now, exactly what is reading stdin?

My suspicion falls on the very-recently-added awk calls. Try changing

(echo "SET autocommit TO 'on';"; awk 'BEGIN {printf "\\set ECHO all\n"}'; cat "$inputdir/sql/$1.sql") |

to

(echo "SET autocommit TO 'on';"; awk 'BEGIN {printf "\\set ECHO all\n"}' </dev/null; cat "$inputdir/sql/$1.sql") |

(there are two places to do this)

OK, that gets it to run all tests, but now virtually all of them fail...

On Wed, 13 Nov 2002 10:06:15 EST, the world broke into rejoicing as
Tom Lane <tgl@sss.pgh.pa.us> said:

"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at> writes:

Why use awk for this at all ? and not:
echo "\\set ECHO all"

I think Bruce is worried about portability; some versions of echo might
do something weird with the backslash. OTOH, it's not obvious to me
that awk is better on that score. Bruce?

The problem is that the regress script isn't pointing to the version of
awk that was picked up in the autoconf phase.

(More detailed comments forwarded directly :-).)

The "real deal" on what happens on Solaris is thus, from the awk FAQ,
where Patrick McPhee writes:

SunOS includes three versions of awk. /usr/bin/awk is the old
(pre-1989) version. /usr/bin/nawk is the new awk which appeared in
1989, and /usr/xpg4/bin/awk is supposed to conform to the single unix
specification. No one knows why Sun continues to ship old awk.

I would be /very/ inclined to trust Patrick's wisdom on this.

So long as we fix up the regression script to grab the "nawk" that
we expect to work, that's probably nicer than figuring out which
echo parameters are needed...
--
(concatenate 'string "cbbrowne" "@ntlug.org")
http://cbbrowne.com/info/wp.html
The first cup of coffee recapitulates phylogeny.

"Nigel J. Andrews" <nandrews@investsystems.co.uk> writes:

FWIW, gmake check and gmake bigcheck pass on:
FreeBSD 3.3-RELEASE #3: Thu Feb 3 23:48:56 GMT 2000

with the expection of:
[snipped]
in the float8 test.

Okay, looks like we need to use float8-fp-exception.out on your
platform. This is a bit surprising since resultmap presently shows

float8/i.86-.*-freebsd=float8-small-is-zero

How shall we distinguish your version of freebsd from the ones that
need the other comparison file?

regards, tom lane

On Wed, 13 Nov 2002, Tom Lane wrote:

"Nigel J. Andrews" <nandrews@investsystems.co.uk> writes:

FWIW, gmake check and gmake bigcheck pass on:
FreeBSD 3.3-RELEASE #3: Thu Feb 3 23:48:56 GMT 2000

with the expection of:
[snipped]
in the float8 test.

Okay, looks like we need to use float8-fp-exception.out on your
platform. This is a bit surprising since resultmap presently shows

float8/i.86-.*-freebsd=float8-small-is-zero

How shall we distinguish your version of freebsd from the ones that
need the other comparison file?

regards, tom lane

Is it necessary, I mean really necessary to distinguish this system? It's quite
an old installation [that ain't broke so I ain't fixed it] and the difference
is only the error message. I hadn't even looked to see if there was a better
expected output file, just accepted it as a normal, acceptable variation in
the regression tests.

I don't know anything about how the tests are put together so I'd have to look
into that before suggesting a way to differentiate my system. Having said that
wouldn't the 3.3-RELEASE string be sufficient?

--
Nigel J. Andrews

"Nigel J. Andrews" <nandrews@investsystems.co.uk> writes:

I don't know anything about how the tests are put together so I'd have
to look into that before suggesting a way to differentiate my
system. Having said that wouldn't the 3.3-RELEASE string be
sufficient?

The mechanism we have in place relies on looking at the output of
config.guess (read the Admin Guide's info about the regression test
resultmap). What does config.guess print for you?

regards, tom lane

Tom Lane writes:

We can't just wait around indefinitely for port reports that may or may
not ever appear. In any case, most of the "<7.3" entries in the list
seem to be various flavors of *BSD; I think it's unlikely we broke
those ...

Note that we have *zero* reports for any flavor of NetBSD and OpenBSD.
That is highly suspicious, and I would not venture a guess about how
likely it is they're broken.

(Maybe you could get someone from Red Hat to confirm the remaining Linux
ports?)

--
Peter Eisentraut peter_e@gmx.net

We can't just wait around indefinitely for port reports that may or may
not ever appear. In any case, most of the "<7.3" entries in the list
seem to be various flavors of *BSD; I think it's unlikely we broke
those ...

Note that we have *zero* reports for any flavor of NetBSD and OpenBSD.
That is highly suspicious, and I would not venture a guess about how
likely it is they're broken.

Where is the list of supported platforms and the email addresses of those
who sent in reports in earlier times? I will email them to do testing...

Chris

"Nigel J. Andrews" <nandrews@investsystems.co.uk> writes:

FWIW, gmake check and gmake bigcheck pass on:
FreeBSD 3.3-RELEASE #3: Thu Feb 3 23:48:56 GMT 2000

with the expection of:
[snipped]
in the float8 test.

Okay, looks like we need to use float8-fp-exception.out on your
platform. This is a bit surprising since resultmap presently shows

float8/i.86-.*-freebsd=float8-small-is-zero

How shall we distinguish your version of freebsd from the ones that
need the other comparison file?

He is using the FreeBSD 3.x series (which is quite old now), whereas most
people are probably using 4.x. I have no problems with regression tests on
4.x so perhaps it's something that changed??

Actually, I've only tested FreeBSD/alpha 4.x - perhaps I should test intel
as well.

Chris

Ports list updated:

http://candle.pha.pa.us/main/writings/pgsql/sgml/supported-platforms.html

---------------------------------------------------------------------------
Nigel J. Andrews wrote:

On Tue, 12 Nov 2002, Tom Lane wrote:

Peter Eisentraut <peter_e@gmx.net> writes:

Bruce Momjian writes:

Are we ready for RC1 yet?

Questionable. We don't even have 50% confirmation coverage for the
supported platforms yet.

We can't just wait around indefinitely for port reports that may or may
not ever appear. In any case, most of the "<7.3" entries in the list
seem to be various flavors of *BSD; I think it's unlikely we broke
those ...

FWIW, gmake check and gmake bigcheck pass on:

FreeBSD 3.3-RELEASE #3: Thu Feb 3 23:48:56 GMT 2000

using:

gcc -v
gcc version 2.7.2.3

and

ld -v
GNU ld version 2.9.1 (with BFD 2.9.1)

with:

./configure --prefix=/usr/local/pgsql-7.2.1 --enable-multibyte --with-perl --with-tcl --enable-odbc --with-pam --enable-syslog --with-tclconfig=/usr/local/lib/tcl8.0 --with-tkconfig=/usr/local/lib/tk8.0 --with-includes=/usr/local/include/tcl8.0:/usr/local/include/tk8.0

with the expection of:

*** 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' ;

in the float8 test.

--
Nigel J. Andrews
Logictree Systems Limited

---------------------------(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) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Peter Eisentraut <peter_e@gmx.net> writes:

Tom Lane writes:

We can't just wait around indefinitely for port reports that may or may
not ever appear. In any case, most of the "<7.3" entries in the list
seem to be various flavors of *BSD; I think it's unlikely we broke
those ...

Note that we have *zero* reports for any flavor of NetBSD and OpenBSD.

Maybe they're both dead platforms? ;-)

Seriously, I agree with Marc's opinion that issuing an RC1 is the best
way to flush out some more port reports. I do not know what else we can
do to get people off their duffs and onto last-minute testing.

(Maybe you could get someone from Red Hat to confirm the remaining Linux
ports?)

Anyone care about the PlayStation 2 port ;=) ? I can get Permaine to
retest if so. Slightly more seriously, we did see a recent report of
trouble on S/390 Linux, but the complainant didn't follow up...

regards, tom lane

Tom Lane wrote:

Peter Eisentraut <peter_e@gmx.net> writes:

Tom Lane writes:

We can't just wait around indefinitely for port reports that may or may
not ever appear. In any case, most of the "<7.3" entries in the list
seem to be various flavors of *BSD; I think it's unlikely we broke
those ...

Note that we have *zero* reports for any flavor of NetBSD and OpenBSD.

Maybe they're both dead platforms? ;-)

Seriously, I agree with Marc's opinion that issuing an RC1 is the best
way to flush out some more port reports. I do not know what else we can
do to get people off their duffs and onto last-minute testing.

(Maybe you could get someone from Red Hat to confirm the remaining Linux
ports?)

Anyone care about the PlayStation 2 port ;=) ? I can get Permaine to
retest if so. Slightly more seriously, we did see a recent report of
trouble on S/390 Linux, but the complainant didn't follow up...

I put an S/390 patch into current CVS --- too risky for 7.3 because it
played with the Power PC ASM instructions. I think we can assume that
port will not work for 7.3.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

I added it to the ports list as OK. We can deal with fixing the
regression falure independently.

---------------------------------------------------------------------------

Nigel J. Andrews wrote:

On Wed, 13 Nov 2002, Tom Lane wrote:

"Nigel J. Andrews" <nandrews@investsystems.co.uk> writes:

FWIW, gmake check and gmake bigcheck pass on:
FreeBSD 3.3-RELEASE #3: Thu Feb 3 23:48:56 GMT 2000

with the expection of:
[snipped]
in the float8 test.

Okay, looks like we need to use float8-fp-exception.out on your
platform. This is a bit surprising since resultmap presently shows

float8/i.86-.*-freebsd=float8-small-is-zero

How shall we distinguish your version of freebsd from the ones that
need the other comparison file?

regards, tom lane

Is it necessary, I mean really necessary to distinguish this system? It's quite
an old installation [that ain't broke so I ain't fixed it] and the difference
is only the error message. I hadn't even looked to see if there was a better
expected output file, just accepted it as a normal, acceptable variation in
the regression tests.

I don't know anything about how the tests are put together so I'd have to look
into that before suggesting a way to differentiate my system. Having said that
wouldn't the 3.3-RELEASE string be sufficient?

--
Nigel J. Andrews

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

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Christopher Kings-Lynne wrote:

We can't just wait around indefinitely for port reports that may or may
not ever appear. In any case, most of the "<7.3" entries in the list
seem to be various flavors of *BSD; I think it's unlikely we broke
those ...

Note that we have *zero* reports for any flavor of NetBSD and OpenBSD.
That is highly suspicious, and I would not venture a guess about how
likely it is they're broken.

Where is the list of supported platforms and the email addresses of those
who sent in reports in earlier times? I will email them to do testing...

List is at:

http://candle.pha.pa.us/main/writings/pgsql/sgml/supported-platforms.html

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

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

How shall we distinguish your version of freebsd from the ones that
need the other comparison file?

He is using the FreeBSD 3.x series (which is quite old now), whereas most
people are probably using 4.x. I have no problems with regression tests on
4.x so perhaps it's something that changed??

How do you feel about resultmap entries

float8/i.86-.*-freebsd3=float8-fp-exception
float8/i.86-.*-freebsd4=float8-small-is-zero

to replace the existing

float8/i.86-.*-freebsd=float8-small-is-zero

Are there (now or in the foreseeable future) freebsd major versions > 4?
We could do

float8/i.86-.*-freebsd[4-9]=float8-small-is-zero

which might or might not be more future-proof.

Actually, I've only tested FreeBSD/alpha 4.x - perhaps I should test intel
as well.

<blink> ain't none of the float8 bsd resultmap entries will match alpha...
so you must be matching the default version?

regards, tom lane

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Tom Lane wrote:

Anyone care about the PlayStation 2 port ;=) ? I can get Permaine to
retest if so. Slightly more seriously, we did see a recent report of
trouble on S/390 Linux, but the complainant didn't follow up...

I put an S/390 patch into current CVS --- too risky for 7.3 because it
played with the Power PC ASM instructions. I think we can assume that
port will not work for 7.3.

Erm, why? The S/390 patch you applied was just a performance
optimization, AFAIK. I tried to track down the problem that the user
reported with S/390, but it appeared that the machine in question had
some serious hardware/software problems, so I gave up.

Cheers,

Neil

--
Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC

Neil Conway wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Tom Lane wrote:

Anyone care about the PlayStation 2 port ;=) ? I can get Permaine to
retest if so. Slightly more seriously, we did see a recent report of
trouble on S/390 Linux, but the complainant didn't follow up...

I put an S/390 patch into current CVS --- too risky for 7.3 because it
played with the Power PC ASM instructions. I think we can assume that
port will not work for 7.3.

Erm, why? The S/390 patch you applied was just a performance
optimization, AFAIK. I tried to track down the problem that the user
reported with S/390, but it appeared that the machine in question had
some serious hardware/software problems, so I gave up.

Oh, I was not sure. I thought it had to do with compile and .asm tags,
and I felt it was too late to take such risks if it could effect larger
working platforms. Were they using non-ASM for S/390 before the patch?
I don't remember.

I guess there was another person who had hardware trouble.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Tom Lane wrote:
<snip>

Anyone care about the PlayStation 2 port ;=) ? I can get Permaine to
retest if so. Slightly more seriously, we did see a recent report of
trouble on S/390 Linux, but the complainant didn't follow up...

Heh Heh Heh

Tom, would you really be able to ask Permaine to retest 7.3? Have a
feeling we might be able to leverage the PlayStation2 brand name here
for the Advocacy project.

:-)

Regards and best wishes,

Justin Clift

regards, tom lane

--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi

Tom Lane <tgl@sss.pgh.pa.us> wrote:
[snip]

Note that we have *zero* reports for any flavor of NetBSD and
OpenBSD.

Maybe they're both dead platforms? ;-)

Well, OpenBSD isn't dead :)
But i have problems compiling 7.3b5 on it (OpenBSD 3.1 i386).
I figured i should give it a go, since nobody else did, but i get many
regression failures.

Then i tried 7.2.3, and it too gives alot of regression failures.

Both were configured with:

./configure \
--with-perl \
--with-openssl \
--enable-odbc \
--with-CXX

And nothing else.

The regression diffs can be found at:
http://gimme.smisk.nu/~mag/pgsql/

Is there some kind of gotcha with compiling pgsql on OpenBSD?
I've never tried it before.

Magnus

Magnus Naeslund(f) <mag@fbab.net> wrote:

Well, OpenBSD isn't dead :)
But i have problems compiling 7.3b5 on it (OpenBSD 3.1 i386).
I figured i should give it a go, since nobody else did, but i get many
regression failures.

OK OK, before anyone rubs my nose in it, i see the fork() failures :)
I just sent the mail without looking.

I'll see what's causing the fork() problems...

Magnus

"Magnus Naeslund(f)" <mag@fbab.net> writes:

OK OK, before anyone rubs my nose in it, i see the fork() failures :)

I'll see what's causing the fork() problems...

Too low processes-per-user limit, likely.

regards, tom lane

Tom Lane <tgl@sss.pgh.pa.us> wrote:

Too low processes-per-user limit, likely.

Yes, ofcourse...
This is what happens when you're in a hurry and tries to make everything
happen at the same time :)

Now it all passes:

OpenBSD 3.1 i386

./configure \
--with-perl \
--enable-odbc \
--with-CXX

All 89 tests passed.
Installation and some small testing seems to work just fine.

Magnus

Ports list updated:

http://candle.pha.pa.us/main/writings/pgsql/sgml/supported-platforms.html

Also, I assume the "(f)" is part of your name, right?

---------------------------------------------------------------------------
Magnus Naeslund(f) wrote:

Tom Lane <tgl@sss.pgh.pa.us> wrote:

Too low processes-per-user limit, likely.

Yes, ofcourse...
This is what happens when you're in a hurry and tries to make everything
happen at the same time :)

Now it all passes:

OpenBSD 3.1 i386

./configure \
--with-perl \
--enable-odbc \
--with-CXX

All 89 tests passed.
Installation and some small testing seems to work just fine.

Magnus

---------------------------(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) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman@candle.pha.pa.us> wrote:

Ports list updated:

http://candle.pha.pa.us/main/writings/pgsql/sgml/supported-
platforms.html

Also, I assume the "(f)" is part of your name, right?

Cool.

No the (f) part is really a mail account thing that (I/we)'ve
traditionally had.
If it's (w) it's posted from my webmail account, if it's (b) it's from
my mag@bahnhof.se account.

Silly thing, but makes/made sense in our context :)

Magnus

Thanks. Fixed.

---------------------------------------------------------------------------

Magnus Naeslund(f) wrote:

Bruce Momjian <pgman@candle.pha.pa.us> wrote:

Ports list updated:

http://candle.pha.pa.us/main/writings/pgsql/sgml/supported-
platforms.html

Also, I assume the "(f)" is part of your name, right?

Cool.

No the (f) part is really a mail account thing that (I/we)'ve
traditionally had.
If it's (w) it's posted from my webmail account, if it's (b) it's from
my mag@bahnhof.se account.

Silly thing, but makes/made sense in our context :)

Magnus

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

On Wed, Nov 13, 2002 at 07:53:00PM +0100, Peter Eisentraut wrote:

Tom Lane writes:

We can't just wait around indefinitely for port reports that may or may
not ever appear. In any case, most of the "<7.3" entries in the list
seem to be various flavors of *BSD; I think it's unlikely we broke
those ...

Note that we have *zero* reports for any flavor of NetBSD and OpenBSD.
That is highly suspicious, and I would not venture a guess about how
likely it is they're broken.

Does all OK on this count?

PostgreSQL 7.3b1 on i386-unknown-netbsdelf1.6H, compiled by GCC 2.95.3

(I'm trying to build bison at the mo to have a go with whatever is in cvs
tip at the moment.)

Cheers,

Patrick

Ports list updated:

http://candle.pha.pa.us/main/writings/pgsql/sgml/supported-platforms.html

---------------------------------------------------------------------------
Patrick Welche wrote:

On Wed, Nov 13, 2002 at 07:53:00PM +0100, Peter Eisentraut wrote:

Tom Lane writes:

We can't just wait around indefinitely for port reports that may or may
not ever appear. In any case, most of the "<7.3" entries in the list
seem to be various flavors of *BSD; I think it's unlikely we broke
those ...

Note that we have *zero* reports for any flavor of NetBSD and OpenBSD.
That is highly suspicious, and I would not venture a guess about how
likely it is they're broken.

Does all OK on this count?

PostgreSQL 7.3b1 on i386-unknown-netbsdelf1.6H, compiled by GCC 2.95.3

(I'm trying to build bison at the mo to have a go with whatever is in cvs
tip at the moment.)

Cheers,

Patrick

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

On Thu, Nov 14, 2002 at 06:13:56PM +0000, Patrick Welche wrote:

On Wed, Nov 13, 2002 at 07:53:00PM +0100, Peter Eisentraut wrote:

Tom Lane writes:

We can't just wait around indefinitely for port reports that may or may
not ever appear. In any case, most of the "<7.3" entries in the list
seem to be various flavors of *BSD; I think it's unlikely we broke
those ...

Note that we have *zero* reports for any flavor of NetBSD and OpenBSD.
That is highly suspicious, and I would not venture a guess about how
likely it is they're broken.

PostgreSQL 7.3b1 on i386-unknown-netbsdelf1.6H, compiled by GCC 2.95.3
PostgreSQL 7.4devel on i386-unknown-netbsdelf1.6K, compiled by GCC 2.95.3

I in fact get geometry.out rather than geometry-positive-zeros.out, but I
think you get the former when you use libm387.so.0 instead of libm.so.0
which isn't exactly the general case for NetBSD, though I have only one
NetBSD/i386 box which can't make use of libm387 (it's a 486SX25)

The 7.4devel was with source from Nov 9 12:27 GMT, so I think rather close
to 7.3, and again with source from just now.

Cheers,

Patrick

Tom Lane wrote:

Seriously, I agree with Marc's opinion that issuing an RC1 is the best
way to flush out some more port reports. I do not know what else we can
do to get people off their duffs and onto last-minute testing.

If testing is the problem, I think publicizing the betas would help
more. I had no idea that 7.3b[2-5] had been released. And looking at the
website, it's not hard to see why:

<http://www.postgresql.org/&gt;: No mention
<http://www14.us.postgresql.org/&gt; (or whatever mirror): No mention
<http://www14.us.postgresql.org/news.html&gt;: No mention
<http://developer.postgresql.org/index.php&gt;: Mentions beta has begun
<http://developer.postgresql.org/beta.php&gt;: Shows latest release at
bottom of page.

I'd really expect to see an announcement on the news page for each beta
release and the latest stable/beta release on the front page. That would
help more than releasing RC1, especially if it's done in the same way.

Thanks,
Scott

Tom, would you really be able to ask Permaine to retest 7.3? Have a
feeling we might be able to leverage the PlayStation2 brand name here
for the Advocacy project.

:-)

Anyone try it on an Xbox yet?

On Thu, Nov 14, 2002 at 09:06:01AM -0500, Tom Lane wrote:

"Magnus Naeslund(f)" <mag@fbab.net> writes:

OK OK, before anyone rubs my nose in it, i see the fork() failures :)

I'll see what's causing the fork() problems...

Too low processes-per-user limit, likely.

Success for
PostgreSQL 7.4devel on acorn32-unknown-netbsd1.6K, compiled by GCC 2.95.3

In other words NetBSD/acorn32-1.6K. The fork() problem for me was not
enough memory, but checking with --schedule=./serial_schedule made it pass
all the tests, except geometry, which leads me to change my mind and
suggest:

Index: resultmap
===================================================================
RCS file: /projects/cvsroot/pgsql-server/src/test/regress/resultmap,v
retrieving revision 1.59
diff -u -r1.59 resultmap
--- resultmap   2002/11/12 20:02:32     1.59
+++ resultmap   2002/11/19 15:20:19
@@ -18,7 +18,6 @@
 geometry/alpha.*-freebsd4.[0-5]=geometry-positive-zeros
 geometry/i.86-.*-openbsd=geometry-positive-zeros
 geometry/sparc-.*-openbsd=geometry-positive-zeros
-geometry/.*-netbsd=geometry-positive-zeros
 geometry/hppa.*-hpux9=geometry-positive-zeros
 geometry/hppa.*-hpux10=geometry-positive-zeros
 geometry/.*-irix6=geometry-positive-zeros

as this acorn32 is running on a StrongARM processor, so has nothing to do
with libm387. Maybe get rid of the geometry-positive-zeros and see if
someone complains and tells me otherwise?

Cheers,

Patrick

Patrick Welche <prlw1@newn.cam.ac.uk> writes:

[remove this:]
-geometry/.*-netbsd=geometry-positive-zeros

as this acorn32 is running on a StrongARM processor, so has nothing to do
with libm387. Maybe get rid of the geometry-positive-zeros and see if
someone complains and tells me otherwise?

Presumably that was put in because it was correct on i86. How do you
feel about changing that entry to

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

rather than deleting it?

regards, tom lane

Ports list updated:

http://candle.pha.pa.us/main/writings/pgsql/sgml/supported-platforms.html

---------------------------------------------------------------------------
Patrick Welche wrote:

On Thu, Nov 14, 2002 at 09:06:01AM -0500, Tom Lane wrote:

"Magnus Naeslund(f)" <mag@fbab.net> writes:

OK OK, before anyone rubs my nose in it, i see the fork() failures :)

I'll see what's causing the fork() problems...

Too low processes-per-user limit, likely.

Success for
PostgreSQL 7.4devel on acorn32-unknown-netbsd1.6K, compiled by GCC 2.95.3

In other words NetBSD/acorn32-1.6K. The fork() problem for me was not
enough memory, but checking with --schedule=./serial_schedule made it pass
all the tests, except geometry, which leads me to change my mind and
suggest:

Index: resultmap
===================================================================
RCS file: /projects/cvsroot/pgsql-server/src/test/regress/resultmap,v
retrieving revision 1.59
diff -u -r1.59 resultmap
--- resultmap   2002/11/12 20:02:32     1.59
+++ resultmap   2002/11/19 15:20:19
@@ -18,7 +18,6 @@
geometry/alpha.*-freebsd4.[0-5]=geometry-positive-zeros
geometry/i.86-.*-openbsd=geometry-positive-zeros
geometry/sparc-.*-openbsd=geometry-positive-zeros
-geometry/.*-netbsd=geometry-positive-zeros
geometry/hppa.*-hpux9=geometry-positive-zeros
geometry/hppa.*-hpux10=geometry-positive-zeros
geometry/.*-irix6=geometry-positive-zeros

as this acorn32 is running on a StrongARM processor, so has nothing to do
with libm387. Maybe get rid of the geometry-positive-zeros and see if
someone complains and tells me otherwise?

Cheers,

Patrick

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

On Tue, Nov 19, 2002 at 10:53:59AM -0500, Tom Lane wrote:

Patrick Welche <prlw1@newn.cam.ac.uk> writes:

[remove this:]
-geometry/.*-netbsd=geometry-positive-zeros

as this acorn32 is running on a StrongARM processor, so has nothing to do
with libm387. Maybe get rid of the geometry-positive-zeros and see if
someone complains and tells me otherwise?

Presumably that was put in because it was correct on i86. How do you
feel about changing that entry to

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

rather than deleting it?

I was under the impression until now that it was geometry.out for i86 using
the libm387 math library, and geometry-positive-zeros for everyone else, but
this acorn32 box is also giving geometry.out, so I must be wrong, in fact
I've just tried not using libm387 on an i386, and it gives geometry.out
too, so we might as well delete it...

BTW cluster.out wants changing now that the ALL in CLUSTER ALL is no longer
allowed..

Cheers,

Patrick

He was testing 7.4devel. That's not the right one.

Bruce Momjian writes:

Ports list updated:

http://candle.pha.pa.us/main/writings/pgsql/sgml/supported-platforms.html

---------------------------------------------------------------------------
Patrick Welche wrote:

On Thu, Nov 14, 2002 at 09:06:01AM -0500, Tom Lane wrote:

"Magnus Naeslund(f)" <mag@fbab.net> writes:

OK OK, before anyone rubs my nose in it, i see the fork() failures :)

I'll see what's causing the fork() problems...

Too low processes-per-user limit, likely.

Success for
PostgreSQL 7.4devel on acorn32-unknown-netbsd1.6K, compiled by GCC 2.95.3

In other words NetBSD/acorn32-1.6K. The fork() problem for me was not
enough memory, but checking with --schedule=./serial_schedule made it pass
all the tests, except geometry, which leads me to change my mind and
suggest:

Index: resultmap
===================================================================
RCS file: /projects/cvsroot/pgsql-server/src/test/regress/resultmap,v
retrieving revision 1.59
diff -u -r1.59 resultmap
--- resultmap   2002/11/12 20:02:32     1.59
+++ resultmap   2002/11/19 15:20:19
@@ -18,7 +18,6 @@
geometry/alpha.*-freebsd4.[0-5]=geometry-positive-zeros
geometry/i.86-.*-openbsd=geometry-positive-zeros
geometry/sparc-.*-openbsd=geometry-positive-zeros
-geometry/.*-netbsd=geometry-positive-zeros
geometry/hppa.*-hpux9=geometry-positive-zeros
geometry/hppa.*-hpux10=geometry-positive-zeros
geometry/.*-irix6=geometry-positive-zeros

as this acorn32 is running on a StrongARM processor, so has nothing to do
with libm387. Maybe get rid of the geometry-positive-zeros and see if
someone complains and tells me otherwise?

Cheers,

Patrick

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

--
Peter Eisentraut peter_e@gmx.net

Backed out. Peter. thanks for spotting that.

Patrick, would you please test 7.3RC1?

---------------------------------------------------------------------------

Peter Eisentraut wrote:

He was testing 7.4devel. That's not the right one.

Bruce Momjian writes:

Ports list updated:

http://candle.pha.pa.us/main/writings/pgsql/sgml/supported-platforms.html

---------------------------------------------------------------------------
Patrick Welche wrote:

On Thu, Nov 14, 2002 at 09:06:01AM -0500, Tom Lane wrote:

"Magnus Naeslund(f)" <mag@fbab.net> writes:

OK OK, before anyone rubs my nose in it, i see the fork() failures :)

I'll see what's causing the fork() problems...

Too low processes-per-user limit, likely.

Success for
PostgreSQL 7.4devel on acorn32-unknown-netbsd1.6K, compiled by GCC 2.95.3

In other words NetBSD/acorn32-1.6K. The fork() problem for me was not
enough memory, but checking with --schedule=./serial_schedule made it pass
all the tests, except geometry, which leads me to change my mind and
suggest:

Index: resultmap
===================================================================
RCS file: /projects/cvsroot/pgsql-server/src/test/regress/resultmap,v
retrieving revision 1.59
diff -u -r1.59 resultmap
--- resultmap   2002/11/12 20:02:32     1.59
+++ resultmap   2002/11/19 15:20:19
@@ -18,7 +18,6 @@
geometry/alpha.*-freebsd4.[0-5]=geometry-positive-zeros
geometry/i.86-.*-openbsd=geometry-positive-zeros
geometry/sparc-.*-openbsd=geometry-positive-zeros
-geometry/.*-netbsd=geometry-positive-zeros
geometry/hppa.*-hpux9=geometry-positive-zeros
geometry/hppa.*-hpux10=geometry-positive-zeros
geometry/.*-irix6=geometry-positive-zeros

as this acorn32 is running on a StrongARM processor, so has nothing to do
with libm387. Maybe get rid of the geometry-positive-zeros and see if
someone complains and tells me otherwise?

Cheers,

Patrick

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

--
Peter Eisentraut peter_e@gmx.net

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Patrick Welche <prlw1@newn.cam.ac.uk> writes:

On Tue, Nov 19, 2002 at 10:53:59AM -0500, Tom Lane wrote:

Presumably that was put in because it was correct on i86. How do you
feel about changing that entry to
geometry/i.86-.*-netbsd=geometry-positive-zeros
rather than deleting it?

I was under the impression until now that it was geometry.out for i86 using
the libm387 math library, and geometry-positive-zeros for everyone else, but
this acorn32 box is also giving geometry.out, so I must be wrong, in fact
I've just tried not using libm387 on an i386, and it gives geometry.out
too, so we might as well delete it...

Hm. Another possibility is that the existing resultmap entry is correct
for some prior netbsd version, but is correct no longer.

AFAIK, all modern hardware claims compliance to the IEEE floating-point
arithmetic standard, so failure to print minus zero as minus zero is
very likely to be a software issue not hardware. That suggests strongly
that the issue is netbsd version (specifically libc version) and not the
hardware platform.

If we knew which netbsd version the behavior changed at, we could put in
some version-specific resultmap entries. But unless someone can provide
datapoints on that, I guess we'll just have to update resultmap to match
recent versions --- ie, take out the entry pointing to
geometry-positive-zeros.

Any objections out there?

regards, tom lane

Tom, can you clarify why -0 is valid. Is it for _small_ near zero
values that are indeed negative?

---------------------------------------------------------------------------

Tom Lane wrote:

Patrick Welche <prlw1@newn.cam.ac.uk> writes:

On Tue, Nov 19, 2002 at 10:53:59AM -0500, Tom Lane wrote:

Presumably that was put in because it was correct on i86. How do you
feel about changing that entry to
geometry/i.86-.*-netbsd=geometry-positive-zeros
rather than deleting it?

I was under the impression until now that it was geometry.out for i86 using
the libm387 math library, and geometry-positive-zeros for everyone else, but
this acorn32 box is also giving geometry.out, so I must be wrong, in fact
I've just tried not using libm387 on an i386, and it gives geometry.out
too, so we might as well delete it...

Hm. Another possibility is that the existing resultmap entry is correct
for some prior netbsd version, but is correct no longer.

AFAIK, all modern hardware claims compliance to the IEEE floating-point
arithmetic standard, so failure to print minus zero as minus zero is
very likely to be a software issue not hardware. That suggests strongly
that the issue is netbsd version (specifically libc version) and not the
hardware platform.

If we knew which netbsd version the behavior changed at, we could put in
some version-specific resultmap entries. But unless someone can provide
datapoints on that, I guess we'll just have to update resultmap to match
recent versions --- ie, take out the entry pointing to
geometry-positive-zeros.

Any objections out there?

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Tom, can you clarify why -0 is valid.

The IEEE spec absolutely thinks that -0 and +0 are distinct entities.
I don't remember why, at one in the morning ... but if you insist I'm
sure that plenty sufficient numerical-analysis reasons can be produced.
The guys who wrote that spec knew what they were doing (that's why it's
been adopted so universally).

regards, tom lane

On Tue, Nov 19, 2002 at 06:22:08PM +0100, Peter Eisentraut wrote:

He was testing 7.4devel. That's not the right one.

What's the difference? (Do I really want to wait another day while this
ancient box compiles it given that the chances of it working under
7.4devel and not under 7.3rcN are smaller than the chances of it
working under 7.3rcN and not under 7.4devel, no?)

Patrick

Patrick Welche wrote:

On Tue, Nov 19, 2002 at 06:22:08PM +0100, Peter Eisentraut wrote:

He was testing 7.4devel. That's not the right one.

What's the difference? (Do I really want to wait another day while this
ancient box compiles it given that the chances of it working under
7.4devel and not under 7.3rcN are smaller than the chances of it
working under 7.3rcN and not under 7.4devel, no?)

Uh, you are right, but we have made a _few_ 7.4 changes so I do think we
need a 7.3-specific test.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman@candle.pha.pa.us> wrote:

Tom, can you clarify why -0 is valid. Is it for _small_ near zero
values that are indeed negative?

"Branch Cuts for Complex Elementary Functions, or Much Ado About
Nothing's Sign Bit" W. Kahan; ch. 7 in _The State of the Art in
Numerical Analysis_ ed. by M. Powell and A. Iserles 1987 Oxford.
Explains how proper respect for -0 eases implementation of conformal
maps of slitted domains arising in studies of flows around obstacles.

Kahan was one of the most important people behind the floating point
standard and won the 1989 Turing Award for his work in numerical computing.
http://www.cs.berkeley.edu/~wkahan/ieee754status/754story.html

Tom Lane writes:

AFAIK, all modern hardware claims compliance to the IEEE floating-point
arithmetic standard, so failure to print minus zero as minus zero is
very likely to be a software issue not hardware. That suggests strongly
that the issue is netbsd version (specifically libc version) and not the
hardware platform.

I could confirm my initial suspicion: it's a *printf() library issue. The
FreeBSD CVS log tells the tale:

http://www.de.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/stdio/vfprintf.c

The next FreeBSD subrelease (4.8?) should have this fixed. OpenBSD is not
fixed. NetBSD and Darwin seem to have temporarily hidden their cvsweb in
shame, but I would assume it's the same issue. Not sure what HP-UX is
doing about it.

--
Peter Eisentraut peter_e@gmx.net

At 1:15 AM -0500 11/20/02, Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Tom, can you clarify why -0 is valid.

The IEEE spec absolutely thinks that -0 and +0 are distinct entities.
I don't remember why, at one in the morning ... but if you insist I'm
sure that plenty sufficient numerical-analysis reasons can be produced.
The guys who wrote that spec knew what they were doing (that's why it's
been adopted so universally).

It's so that 1/(1/-infinity) == -infinity. There are probably other
reasons as well.

I'm just guessing here, but it's possible NetBSD acquired the bug by
trying to be functional on non-IEEE hardware. I hope that whoever
found the problem (I don't see that in this thread) filed a bug
report with NetBSD.
--
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu

On Wed, Nov 20, 2002 at 06:48:15PM +0100, Peter Eisentraut wrote:

Tom Lane writes:

AFAIK, all modern hardware claims compliance to the IEEE floating-point
arithmetic standard, so failure to print minus zero as minus zero is
very likely to be a software issue not hardware. That suggests strongly
that the issue is netbsd version (specifically libc version) and not the
hardware platform.

I could confirm my initial suspicion: it's a *printf() library issue. The
FreeBSD CVS log tells the tale:

http://www.de.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/stdio/vfprintf.c

The next FreeBSD subrelease (4.8?) should have this fixed. OpenBSD is not
fixed. NetBSD and Darwin seem to have temporarily hidden their cvsweb in
shame, but I would assume it's the same issue. Not sure what HP-UX is
doing about it.

Right, the equivalent for NetBSD vfprintf.c is:

revision 1.40
date: 2001/11/28 11:58:22; author: kleink; state: Exp; lines: +4 -4
Since we're returned the sign of a floating-point number by __dtoa(),
use that to decide whether to include a minus sign in the result.
Fixes printing -0.0, and thus PR lib/3137.

NetBSD 1.5 has revision 1.32, NetBSD 1.6 has revision 1.42

Well spotted,

Patrick

Patrick Welche <prlw1@newn.cam.ac.uk> writes:

Right, the equivalent for NetBSD vfprintf.c is:
revision 1.40
date: 2001/11/28 11:58:22; author: kleink; state: Exp; lines: +4 -4
Since we're returned the sign of a floating-point number by __dtoa(),
use that to decide whether to include a minus sign in the result.
Fixes printing -0.0, and thus PR lib/3137.

NetBSD 1.5 has revision 1.32, NetBSD 1.6 has revision 1.42

Ah-hah, so it is a version issue --- we could make the resultmap line
something like
geometry/.*-netbsd1.[0-5]=geometry-positive-zeros

Would you confirm what config.guess prints on your box --- in
particular, is there a dot in the version number?

regards, tom lane

Peter Eisentraut <peter_e@gmx.net> writes:

The next FreeBSD subrelease (4.8?) should have this fixed. OpenBSD is not
fixed. NetBSD and Darwin seem to have temporarily hidden their cvsweb in
shame, but I would assume it's the same issue. Not sure what HP-UX is
doing about it.

HP has evidently fixed it in HPUX 11. I do not think they intend to
change the behavior of HPUX 10 anymore, so the existing resultmap
entries for geometry/hppa seem okay.

regards, tom lane

On Wed, Nov 20, 2002 at 01:21:47PM -0500, Tom Lane wrote:

Patrick Welche <prlw1@newn.cam.ac.uk> writes:

...

NetBSD 1.5 has revision 1.32, NetBSD 1.6 has revision 1.42

Ah-hah, so it is a version issue --- we could make the resultmap line
something like
geometry/.*-netbsd1.[0-5]=geometry-positive-zeros

Would you confirm what config.guess prints on your box --- in
particular, is there a dot in the version number?

Yes:

NetBSD/i386-1.6H i386-unknown-netbsdelf1.6H (checked 7.3rc1)
NetBSD/acorn32-1.6K arm-unknown-netbsdelf1.6K (still building 7.3rc1)

(several NetBSDs probably come up with arm-unknown..)

Cheers,

Patrick

Patrick Welche <prlw1@newn.cam.ac.uk> writes:

On Wed, Nov 20, 2002 at 01:21:47PM -0500, Tom Lane wrote:

Ah-hah, so it is a version issue --- we could make the resultmap line
something like
geometry/.*-netbsd1.[0-5]=geometry-positive-zeros

NetBSD/i386-1.6H i386-unknown-netbsdelf1.6H (checked 7.3rc1)
NetBSD/acorn32-1.6K arm-unknown-netbsdelf1.6K (still building 7.3rc1)

Hm, is that "elf" always there? I'm a little uncomfortable with making
the pattern be
geometry/.*-netbsd.*1.[0-5]=geometry-positive-zeros
as this seems way too lax ...

regards, tom lane

On Wed, Nov 20, 2002 at 01:51:28PM -0500, Tom Lane wrote:

Patrick Welche <prlw1@newn.cam.ac.uk> writes:

On Wed, Nov 20, 2002 at 01:21:47PM -0500, Tom Lane wrote:

Ah-hah, so it is a version issue --- we could make the resultmap line
something like
geometry/.*-netbsd1.[0-5]=geometry-positive-zeros

NetBSD/i386-1.6H i386-unknown-netbsdelf1.6H (checked 7.3rc1)
NetBSD/acorn32-1.6K arm-unknown-netbsdelf1.6K (still building 7.3rc1)

Hm, is that "elf" always there? I'm a little uncomfortable with making
the pattern be
geometry/.*-netbsd.*1.[0-5]=geometry-positive-zeros
as this seems way too lax ...

"elf" won't always be there - that acorn32 is a case in point: it became
elf for 1.6. acorn26 has always been elf. I can't remember when i386 became
elf.. (In fact the old config.guess that comes with NeTraMet44b8 says
i386-unknown-netbsd1.6K - so maybe the config.guess cvs log may shed some
light)

!!!! Just realised: the answers I gave above were with the config.guess from
automake 1.7a!

% uname -srmp
NetBSD 1.6K acorn32 arm
% postgresql-7.3rc1/config/config.guess
acorn32-unknown-netbsd1.6K
% automake/lib/config.guess
arm-unknown-netbsdelf1.6K

Confusing..

Patrick

Patrick Welche <prlw1@newn.cam.ac.uk> writes:

!!!! Just realised: the answers I gave above were with the config.guess from
automake 1.7a!

% uname -srmp
NetBSD 1.6K acorn32 arm
% postgresql-7.3rc1/config/config.guess
acorn32-unknown-netbsd1.6K
% automake/lib/config.guess
arm-unknown-netbsdelf1.6K

Mph. Okay, I guess we'd better expend two patterns on this:

geometry/.*-netbsd1.[0-5]=geometry-positive-zeros
geometry/.*-netbsdelf1.[0-5]=geometry-positive-zeros

Will make it so.

regards, tom lane

On Wed, Nov 20, 2002 at 09:33:41AM -0500, Bruce Momjian wrote:

Patrick Welche wrote:

On Tue, Nov 19, 2002 at 06:22:08PM +0100, Peter Eisentraut wrote:

He was testing 7.4devel. That's not the right one.

What's the difference? (Do I really want to wait another day while this
ancient box compiles it given that the chances of it working under
7.4devel and not under 7.3rcN are smaller than the chances of it
working under 7.3rcN and not under 7.4devel, no?)

Uh, you are right, but we have made a _few_ 7.4 changes so I do think we
need a 7.3-specific test.

OK - did 7.3rc1 successfully on NetBSD-1.6K/acorn32 and NetBSD-16H/i386

On Wed, Nov 20, 2002 at 09:33:41AM -0500, Bruce Momjian wrote:

Patrick Welche wrote:

On Tue, Nov 19, 2002 at 06:22:08PM +0100, Peter Eisentraut wrote:

He was testing 7.4devel. That's not the right one.

What's the difference? (Do I really want to wait another day while this
ancient box compiles it given that the chances of it working under
7.4devel and not under 7.3rcN are smaller than the chances of it
working under 7.3rcN and not under 7.4devel, no?)

Uh, you are right, but we have made a _few_ 7.4 changes so I do think we
need a 7.3-specific test.

And yes, you are right, I've just spotted a little change: 7.3b1 dump
imported into 7.4devel database needs "value" quoted in

CREATE TABLE amount (
id serial NOT NULL,
value integer
);

so "value"'s keyword status must have changed..

Cheers,

Patrick

Ports list updated:

http://candle.pha.pa.us/main/writings/pgsql/sgml/supported-platforms.html

---------------------------------------------------------------------------

Patrick Welche wrote:

On Wed, Nov 20, 2002 at 09:33:41AM -0500, Bruce Momjian wrote:

Patrick Welche wrote:

On Tue, Nov 19, 2002 at 06:22:08PM +0100, Peter Eisentraut wrote:

He was testing 7.4devel. That's not the right one.

What's the difference? (Do I really want to wait another day while this
ancient box compiles it given that the chances of it working under
7.4devel and not under 7.3rcN are smaller than the chances of it
working under 7.3rcN and not under 7.4devel, no?)

Uh, you are right, but we have made a _few_ 7.4 changes so I do think we
need a 7.3-specific test.

OK - did 7.3rc1 successfully on NetBSD-1.6K/acorn32 and NetBSD-16H/i386

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

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

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

At 1:51 PM -0500 11/20/02, Tom Lane wrote:

Patrick Welche <prlw1@newn.cam.ac.uk> writes:

On Wed, Nov 20, 2002 at 01:21:47PM -0500, Tom Lane wrote:

Ah-hah, so it is a version issue --- we could make the resultmap line
something like
geometry/.*-netbsd1.[0-5]=geometry-positive-zeros

NetBSD/i386-1.6H i386-unknown-netbsdelf1.6H (checked 7.3rc1)
NetBSD/acorn32-1.6K arm-unknown-netbsdelf1.6K (still building 7.3rc1)

Hm, is that "elf" always there? I'm a little uncomfortable with making
the pattern be
geometry/.*-netbsd.*1.[0-5]=geometry-positive-zeros
as this seems way too lax ...

A version like 1.6[A-Z] is a -current, not a release version from in
between 1.5.x and 1.6.

Different NetBSD ports have converted to elf at different times and
not all ports are using elf even with 1.6 released.
--
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu

Now, Solaris seems to be running all the tests but failing something like
29 out of 85 of them.

With a vanilla ./configure;make, I get this on a make check:

============== running regression test queries ==============
parallel group (13 tests): char int8 oid int2 int4 varchar name boolean
text float4 float8 bit numeric
boolean ... ok
char ... ok
name ... ok
varchar ... ok
text ... ok
int2 ... ok
int4 ... ok
int8 ... ok
oid ... ok
float4 ... ok
float8 ... ok
bit ... ok
numeric ... ok
test strings ... ok
test numerology ... ok
parallel group (20 tests): date interval comments lseg path box time
point polygon abstime inet circle tinterval reltime timetz timestamp
timestamptz type_sanity opr_sanity oidjoins
point ... ok
lseg ... ok
box ... ok
path ... ok
polygon ... ok
circle ... ok
date ... ok
time ... ok
timetz ... ok
timestamp ... ok
timestamptz ... ok
interval ... ok
abstime ... ok
reltime ... ok
tinterval ... ok
inet ... ok
comments ... ok
oidjoins ... ok
type_sanity ... ok
opr_sanity ... FAILED
test geometry ... ok
test horology ... ok
test insert ... ok
test create_function_1 ... ok
test create_type ... ok
test create_table ... ok
test create_function_2 ... ok
test copy ... ok
parallel group (7 tests): create_aggregate create_operator triggers
constraints inherit vacuum create_misc
constraints ... FAILED
triggers ... FAILED
create_misc ... ok
create_aggregate ... FAILED
create_operator ... FAILED
inherit ... FAILED
vacuum ... FAILED
parallel group (2 tests): create_view create_index
create_index ... FAILED
create_view ... FAILED
test sanity_check ... ok
test errors ... ok
test select ... ok
parallel group (16 tests): select_implicit random select_distinct
select_into transactions union select_distinct_on portals arrays
select_having case subselect aggregates join hash_index btree_index
select_into ... ok
select_distinct ... ok
select_distinct_on ... ok
select_implicit ... FAILED
select_having ... ok
subselect ... ok
union ... FAILED
case ... ok
join ... ok
aggregates ... FAILED
transactions ... ok
random ... failed (ignored)
portals ... ok
arrays ... ok
btree_index ... ok
hash_index ... ok
test privileges ... ok
test misc ... FAILED
parallel group (5 tests): select_views portals_p2 cluster rules
foreign_key
select_views ... FAILED
portals_p2 ... ok
rules ... FAILED
foreign_key ... FAILED
cluster ... FAILED
parallel group (11 tests): prepare truncate copy2 temp domain limit
conversion rangefuncs without_oid plpgsql alter_table
limit ... FAILED
plpgsql ... FAILED
copy2 ... FAILED
temp ... ok
domain ... FAILED
rangefuncs ... FAILED
prepare ... FAILED
without_oid ... ok
conversion ... FAILED
truncate ... ok
alter_table ... FAILED
============== shutting down postmaster ==============

=====================================================
26 of 89 tests failed, 1 of these failures 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[2]: *** [check] Error 1
make[2]: Leaving directory
`/home/smarlowe/postgresql-7.3rc2/src/test/regress'
make[1]: *** [check] Error 2
make[1]: Leaving directory `/home/smarlowe/postgresql-7.3rc2/src/test'
make: *** [check] Error 2

If you'd like the output the of the -x version, let me know.

Please try RC2; this is fixed there.

---------------------------------------------------------------------------

scott.marlowe wrote:

Now, Solaris seems to be running all the tests but failing something like
29 out of 85 of them.

With a vanilla ./configure;make, I get this on a make check:

============== running regression test queries ==============
parallel group (13 tests): char int8 oid int2 int4 varchar name boolean
text float4 float8 bit numeric
boolean ... ok
char ... ok
name ... ok
varchar ... ok
text ... ok
int2 ... ok
int4 ... ok
int8 ... ok
oid ... ok
float4 ... ok
float8 ... ok
bit ... ok
numeric ... ok
test strings ... ok
test numerology ... ok
parallel group (20 tests): date interval comments lseg path box time
point polygon abstime inet circle tinterval reltime timetz timestamp
timestamptz type_sanity opr_sanity oidjoins
point ... ok
lseg ... ok
box ... ok
path ... ok
polygon ... ok
circle ... ok
date ... ok
time ... ok
timetz ... ok
timestamp ... ok
timestamptz ... ok
interval ... ok
abstime ... ok
reltime ... ok
tinterval ... ok
inet ... ok
comments ... ok
oidjoins ... ok
type_sanity ... ok
opr_sanity ... FAILED
test geometry ... ok
test horology ... ok
test insert ... ok
test create_function_1 ... ok
test create_type ... ok
test create_table ... ok
test create_function_2 ... ok
test copy ... ok
parallel group (7 tests): create_aggregate create_operator triggers
constraints inherit vacuum create_misc
constraints ... FAILED
triggers ... FAILED
create_misc ... ok
create_aggregate ... FAILED
create_operator ... FAILED
inherit ... FAILED
vacuum ... FAILED
parallel group (2 tests): create_view create_index
create_index ... FAILED
create_view ... FAILED
test sanity_check ... ok
test errors ... ok
test select ... ok
parallel group (16 tests): select_implicit random select_distinct
select_into transactions union select_distinct_on portals arrays
select_having case subselect aggregates join hash_index btree_index
select_into ... ok
select_distinct ... ok
select_distinct_on ... ok
select_implicit ... FAILED
select_having ... ok
subselect ... ok
union ... FAILED
case ... ok
join ... ok
aggregates ... FAILED
transactions ... ok
random ... failed (ignored)
portals ... ok
arrays ... ok
btree_index ... ok
hash_index ... ok
test privileges ... ok
test misc ... FAILED
parallel group (5 tests): select_views portals_p2 cluster rules
foreign_key
select_views ... FAILED
portals_p2 ... ok
rules ... FAILED
foreign_key ... FAILED
cluster ... FAILED
parallel group (11 tests): prepare truncate copy2 temp domain limit
conversion rangefuncs without_oid plpgsql alter_table
limit ... FAILED
plpgsql ... FAILED
copy2 ... FAILED
temp ... ok
domain ... FAILED
rangefuncs ... FAILED
prepare ... FAILED
without_oid ... ok
conversion ... FAILED
truncate ... ok
alter_table ... FAILED
============== shutting down postmaster ==============

=====================================================
26 of 89 tests failed, 1 of these failures 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[2]: *** [check] Error 1
make[2]: Leaving directory
`/home/smarlowe/postgresql-7.3rc2/src/test/regress'
make[1]: *** [check] Error 2
make[1]: Leaving directory `/home/smarlowe/postgresql-7.3rc2/src/test'
make: *** [check] Error 2

If you'd like the output the of the -x version, let me know.

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

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

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Can you send in the regression.diffs file?

Chris

----- Original Message -----
From: "scott.marlowe" <scott.marlowe@ihs.com>
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: "PostgreSQL-development" <pgsql-hackers@postgresql.org>
Sent: Monday, November 25, 2002 1:41 PM
Subject: [HACKERS] Solaris still failing RC2

On Mon, 25 Nov 2002, Bruce Momjian wrote:

Please try RC2; this is fixed there.

Ummmm. That was with rc2

scott.marlowe wrote:

On Mon, 25 Nov 2002, Bruce Momjian wrote:

Please try RC2; this is fixed there.

Ummmm. That was with rc2

Oh. That's bad.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

On Mon, 25 Nov 2002, Christopher Kings-Lynne wrote:

Can you send in the regression.diffs file?

Chris

----- Original Message -----
From: "scott.marlowe" <scott.marlowe@ihs.com>
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: "PostgreSQL-development" <pgsql-hackers@postgresql.org>
Sent: Monday, November 25, 2002 1:41 PM
Subject: [HACKERS] Solaris still failing RC2

Now, Solaris seems to be running all the tests but failing something like
29 out of 85 of them.

With a vanilla ./configure;make, I get this on a make check:

Never mind, I'm getting block not available errors in the diff files.

Which makes no sense, as I have 300 Meg free on the my /tmp and 18 gig
free on my home directory.

Oh well, I see someone else has proofed these out on the supported
platforms page anyway...

On Mon, 25 Nov 2002, Christopher Kings-Lynne wrote:

Can you send in the regression.diffs file?

OK, after a bit of hair pulling, and figuring out I was running out of
space because of quotas, I've gotten it to run with only one failure,
which was because of having too many files open, and that was trying to
load plpgsql.so. So, I'm sure that the other guy's test is fine, and we
just have really crappily configured boxes around here (and I'm not the
SunOS/Solaris SA, so can't really fix it, and probably can't get it fixed
anytime soon.)