Thread: RC1?
Are we ready for RC1 yet? -- 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, Pennsylvania19073
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'sjust 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'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 > > ---------------------------(end of broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org >
> > 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
Attachment
"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 ?
Attachment
"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, Pennsylvania19073
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?
"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
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:
> 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 seds/ //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_TBLf; ! ERROR: Bad float8 input format -- overflow SELECT '' AS bad, f.f1 ^ '1e200' from FLOAT8_TBL f; ERROR: pow() result isout 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_TBLf; ! ERROR: floating point exception! The last floating point operation either exceeded legal rangesor was a divide by zeroSELECT '' AS bad, f.f1 ^ '1e200' from FLOAT8_TBL f; ERROR: pow() result is out of range SELECT '' AS bad, ln(f.f1) fromFLOAT8_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
shoulduse 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 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.
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...
"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, Pennsylvania19073
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, Pennsylvania19073
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, Pennsylvania19073
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, Pennsylvania19073
"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, Pennsylvania19073
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, Pennsylvania19073
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, Pennsylvania19073
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, Pennsylvania19073
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/>: No mention <http://www14.us.postgresql.org/> (or whatever mirror): No mention <http://www14.us.postgresql.org/news.html>: No mention <http://developer.postgresql.org/index.php>: Mentions beta has begun <http://developer.postgresql.org/beta.php>: 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 forPostgreSQL 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-zerosgeometry/i.86-.*-openbsd=geometry-positive-zerosgeometry/sparc-.*-openbsd=geometry-positive-zeros -geometry/.*-netbsd=geometry-positive-zerosgeometry/hppa.*-hpux9=geometry-positive-zerosgeometry/hppa.*-hpux10=geometry-positive-zerosgeometry/.*-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, Pennsylvania19073
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, Pennsylvania19073
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, Pennsylvania19073
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
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, Pennsylvania19073
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, Pennsylvania19073
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, Pennsylvania19073
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:
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.)
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
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