Thread

RC1?

Bruce Momjian <pgman@candle.pha.pa.us> — 2002-11-12T05:05:16Z

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, Pennsylvania 19073

Re: RC1?

Tom Lane <tgl@sss.pgh.pa.us> — 2002-11-12T05:26:30Z

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

Re: RC1?

Vince Vielhaber <vev@michvhf.com> — 2002-11-12T11:03:58Z

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.

Re: RC1?

Tatsuo Ishii <t-ishii@sra.co.jp> — 2002-11-12T11:25:00Z

> 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

Re: RC1?

Marc G. Fournier <scrappy@hub.org> — 2002-11-12T15:45:24Z

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

Re: RC1?

Peter Eisentraut <peter_e@gmx.net> — 2002-11-12T20:36:25Z

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

Re: RC1?

Tom Lane <tgl@sss.pgh.pa.us> — 2002-11-12T21:27:11Z

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

Re: RC1?

Robert Treat <xzilla@users.sourceforge.net> — 2002-11-12T21:59:23Z

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

Re: RC1?

scott.marlowe <scott.marlowe@ihs.com> — 2002-11-12T22:21:40Z

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.

Re: RC1?

scott.marlowe <scott.marlowe@ihs.com> — 2002-11-12T22:39:16Z

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?

Re: RC1?

scott.marlowe <scott.marlowe@ihs.com> — 2002-11-12T23:01:32Z

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.

Re: RC1?

scott.marlowe <scott.marlowe@ihs.com> — 2002-11-12T23:02:57Z

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?

Re: RC1?

Tom Lane <tgl@sss.pgh.pa.us> — 2002-11-12T23:04:23Z

"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

Re: RC1?

Tom Lane <tgl@sss.pgh.pa.us> — 2002-11-12T23:21:15Z

"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

Re: RC1?

scott.marlowe <scott.marlowe@ihs.com> — 2002-11-12T23:41:50Z

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.

Re: RC1?

Tom Lane <tgl@sss.pgh.pa.us> — 2002-11-13T00:04:29Z

"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

Re: RC1?

Nigel J. Andrews <nandrews@investsystems.co.uk> — 2002-11-13T12:28:59Z

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

Re: RC1?

scott.marlowe <scott.marlowe@ihs.com> — 2002-11-13T16:38:13Z

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

Re: RC1?

Tom Lane <tgl@sss.pgh.pa.us> — 2002-11-13T16:58:04Z

"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

Re: RC1?

Nigel J. Andrews <nandrews@investsystems.co.uk> — 2002-11-13T17:04:30Z

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

Re: RC1?

Tom Lane <tgl@sss.pgh.pa.us> — 2002-11-13T17:33:50Z

"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

Re: RC1?

Peter Eisentraut <peter_e@gmx.net> — 2002-11-13T18:53:00Z

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

Re: RC1?

Christopher Kings-Lynne <chriskl@familyhealth.com.au> — 2002-11-14T03:25:07Z

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

Re: RC1?

Christopher Kings-Lynne <chriskl@familyhealth.com.au> — 2002-11-14T03:30:30Z

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

Re: RC1?

Bruce Momjian <pgman@candle.pha.pa.us> — 2002-11-14T03:59:25Z

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

Re: RC1?

Tom Lane <tgl@sss.pgh.pa.us> — 2002-11-14T04:12:20Z

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

Re: RC1?

Bruce Momjian <pgman@candle.pha.pa.us> — 2002-11-14T04:15:43Z

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

Re: RC1?

Bruce Momjian <pgman@candle.pha.pa.us> — 2002-11-14T05:00:06Z

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

Re: RC1?

Bruce Momjian <pgman@candle.pha.pa.us> — 2002-11-14T05:02:43Z

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

Re: RC1?

Tom Lane <tgl@sss.pgh.pa.us> — 2002-11-14T05:17:40Z

"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

Re: RC1?

Neil Conway <neilc@samurai.com> — 2002-11-14T05:43:32Z

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

Re: RC1?

Bruce Momjian <pgman@candle.pha.pa.us> — 2002-11-14T05:46:55Z

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

Re: RC1?

Justin Clift <justin@postgresql.org> — 2002-11-14T05:50:58Z

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

Re: RC1?

Magnus Naeslund(f) <mag@fbab.net> — 2002-11-14T11:14:41Z

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

Re: RC1?

Magnus Naeslund(f) <mag@fbab.net> — 2002-11-14T12:44:57Z

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

Re: RC1?

Tom Lane <tgl@sss.pgh.pa.us> — 2002-11-14T14:06:01Z

"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

Add OpenBSD 3.1 i386 to supported platforms (was: RC1?)

Magnus Naeslund(f) <mag@fbab.net> — 2002-11-14T14:20:45Z

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

Re: Add OpenBSD 3.1 i386 to supported platforms (was: RC1?)

Bruce Momjian <pgman@candle.pha.pa.us> — 2002-11-14T14:24:01Z

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

Re: Add OpenBSD 3.1 i386 to supported platforms (was: RC1?)

Magnus Naeslund(f) <mag@fbab.net> — 2002-11-14T14:36:18Z

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

Re: Add OpenBSD 3.1 i386 to supported platforms (was: RC1?)

Bruce Momjian <pgman@candle.pha.pa.us> — 2002-11-14T14:53:33Z

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

Re: RC1?

Patrick Welche <prlw1@newn.cam.ac.uk> — 2002-11-14T18:13:56Z

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

Re: RC1?

Bruce Momjian <pgman@candle.pha.pa.us> — 2002-11-14T18:39:23Z

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

Re: RC1?

Patrick Welche <prlw1@newn.cam.ac.uk> — 2002-11-14T18:53:52Z

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

Re: RC1?

Scott Lamb <slamb@slamb.org> — 2002-11-14T21:42:42Z

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

Re: RC1?

Matthew T. O'Connor <matthew@zeut.net> — 2002-11-14T23:05:49Z

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

Re: RC1?

Patrick Welche <prlw1@newn.cam.ac.uk> — 2002-11-19T15:24:47Z

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

Re: RC1?

Tom Lane <tgl@sss.pgh.pa.us> — 2002-11-19T15:53:59Z

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

Re: RC1?

Bruce Momjian <pgman@candle.pha.pa.us> — 2002-11-19T16:39:58Z

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

Re: RC1?

Patrick Welche <prlw1@newn.cam.ac.uk> — 2002-11-19T17:05:26Z

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

Re: RC1?

Peter Eisentraut <peter_e@gmx.net> — 2002-11-19T17:22:08Z

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

Re: RC1?

Bruce Momjian <pgman@candle.pha.pa.us> — 2002-11-19T18:03:16Z

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

Geometry test on NetBSD (was Re: [HACKERS] RC1?)

Tom Lane <tgl@sss.pgh.pa.us> — 2002-11-20T06:06:36Z

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

Re: Geometry test on NetBSD (was Re: [HACKERS] RC1?)

Bruce Momjian <pgman@candle.pha.pa.us> — 2002-11-20T06:08:34Z

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

Re: Geometry test on NetBSD (was Re: [HACKERS] RC1?)

Tom Lane <tgl@sss.pgh.pa.us> — 2002-11-20T06:15:12Z

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

Re: RC1?

Patrick Welche <prlw1@newn.cam.ac.uk> — 2002-11-20T12:28:49Z

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

Re: RC1?

Bruce Momjian <pgman@candle.pha.pa.us> — 2002-11-20T14:33:41Z

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

Re: Geometry test on NetBSD (was Re: [HACKERS] RC1?)

Ken Hirsch <kahirsch@bellsouth.net> — 2002-11-20T17:02:38Z

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

Re: Geometry test on NetBSD (was Re: [HACKERS] RC1?)

Peter Eisentraut <peter_e@gmx.net> — 2002-11-20T17:48:15Z

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

Re: Geometry test on NetBSD (was Re: [HACKERS] RC1?)

Henry B. Hotz <hotz@jpl.nasa.gov> — 2002-11-20T17:55:29Z

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

Re: Geometry test on NetBSD (was Re: [HACKERS] RC1?)

Patrick Welche <prlw1@newn.cam.ac.uk> — 2002-11-20T17:57:53Z

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

Re: Geometry test on NetBSD (was Re: [HACKERS] RC1?)

Tom Lane <tgl@sss.pgh.pa.us> — 2002-11-20T18:21:47Z

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

Re: Geometry test on NetBSD (was Re: [HACKERS] RC1?)

Tom Lane <tgl@sss.pgh.pa.us> — 2002-11-20T18:23:34Z

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

Re: Geometry test on NetBSD (was Re: [HACKERS] RC1?)

Patrick Welche <prlw1@newn.cam.ac.uk> — 2002-11-20T18:44:12Z

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

Re: Geometry test on NetBSD (was Re: [HACKERS] RC1?)

Tom Lane <tgl@sss.pgh.pa.us> — 2002-11-20T18:51:28Z

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

Re: Geometry test on NetBSD (was Re: [HACKERS] RC1?)

Patrick Welche <prlw1@newn.cam.ac.uk> — 2002-11-20T19:18:14Z

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

Re: Geometry test on NetBSD (was Re: [HACKERS] RC1?)

Tom Lane <tgl@sss.pgh.pa.us> — 2002-11-20T20:13:26Z

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

Re: RC1?

Patrick Welche <prlw1@newn.cam.ac.uk> — 2002-11-20T20:47:45Z

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

Re: RC1?

Patrick Welche <prlw1@newn.cam.ac.uk> — 2002-11-20T21:13:13Z

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

Re: RC1?

Bruce Momjian <pgman@candle.pha.pa.us> — 2002-11-20T22:02:02Z

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

Re: Geometry test on NetBSD (was Re: [HACKERS] RC1?)

Henry B. Hotz <hotz@jpl.nasa.gov> — 2002-11-21T01:22:14Z

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

Solaris still failing RC2

scott.marlowe <scott.marlowe@ihs.com> — 2002-11-25T21:41:53Z

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.

Re: Solaris still failing RC2

Bruce Momjian <pgman@candle.pha.pa.us> — 2002-11-25T21:49:21Z

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

Re: Solaris still failing RC2

Christopher Kings-Lynne <chriskl@familyhealth.com.au> — 2002-11-25T22:03:43Z

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:

Re: Solaris still failing RC2

scott.marlowe <scott.marlowe@ihs.com> — 2002-11-25T22:04:36Z

On Mon, 25 Nov 2002, Bruce Momjian wrote:

> 
> Please try RC2;  this is fixed there.

Ummmm.  That was with rc2

Re: Solaris still failing RC2

Bruce Momjian <pgman@candle.pha.pa.us> — 2002-11-25T22:06:34Z

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

Re: Solaris still failing RC2

scott.marlowe <scott.marlowe@ihs.com> — 2002-11-25T22:24:42Z

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

Re: Solaris still failing RC2

scott.marlowe <scott.marlowe@ihs.com> — 2002-11-25T23:06:19Z

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