7.3b3 on MacOSX 10.2.1

Ports list updated:

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

---------------------------------------------------------------------------
Adam Witney wrote:

Just to update the list of supported platforms, 7.3b3 compiles and passes
all the regression tests on MacOSX 10.2.1

Although don't know if this is relevant but this appears when running the
tests:

parallel group (20 tests): ./pg_regress: fork: Resource temporarily
unavailable
./pg_regress: fork: Resource temporarily unavailable
comments lseg box path timetz point circle reltime tinterval date inet
interval timestamp time abstime polygon timestamptz oidjoins

Cheers

Adam

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

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

Adam Witney <awitney@sghms.ac.uk> writes:

Just to update the list of supported platforms, 7.3b3 compiles and passes
all the regression tests on MacOSX 10.2.1

Although don't know if this is relevant but this appears when running the
tests:

parallel group (20 tests): ./pg_regress: fork: Resource temporarily
unavailable
./pg_regress: fork: Resource temporarily unavailable
comments lseg box path timetz point circle reltime tinterval date inet
interval timestamp time abstime polygon timestamptz oidjoins

This suggests that you are hitting the per-user limit on the number of
processes you can have; try raising that limit.

I'd expect one of the tests not to have been run when that message
appears; did you really get successful matches for all tests?

regards, tom lane

So first off, what's the best way to tell from a cvs snapshot which "release" (if any) that snapshot is?

I just (2pm) grabbed a full clean cvs checkout, and tried to run the regression tests. This is on a Macintosh G4/450 dual CPU with 512MB.

'make runcheck' in src/test/regress/ fails with:

<snip from src/test/regress/log/install.log>

rm -f libecpg.so && \
ln -s libecpg.so.3.4.0 libecpg.so
make -C preproc install
make -C ../../../../src/port all
make[6]: Nothing to be done for `all'.
bison -y -d preproc.y
preproc.y:5560: fatal error: maximum table size (32767) exceeded
make[5]: *** [preproc.h] Error 1
make[4]: *** [install] Error 2
make[3]: *** [install] Error 2
make[2]: *** [install] Error 2
make[1]: *** [install] Error 2

</snip>

-pmb

Peter Bierman <bierman@apple.com> writes:

So first off, what's the best way to tell from a cvs snapshot which
"release" (if any) that snapshot is?

configure.in, perhaps?

'make runcheck' in src/test/regress/ fails with:

bison -y -d preproc.y
preproc.y:5560: fatal error: maximum table size (32767) exceeded

You need bison 1.50 or greater to build the new ecpg (due to a bison
limitation).

Cheers,

Neil

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

At 6:11 PM -0500 10/29/02, Neil Conway wrote:

Peter Bierman <bierman@apple.com> writes:

So first off, what's the best way to tell from a cvs snapshot which
"release" (if any) that snapshot is?

configure.in, perhaps?

Ah, thanks. 7.3b3 it is then.

'make runcheck' in src/test/regress/ fails with:

bison -y -d preproc.y
preproc.y:5560: fatal error: maximum table size (32767) exceeded

You need bison 1.50 or greater to build the new ecpg (due to a bison
limitation).

Ok. After upgrading to bison-1.75, all regression tests pass except:

*** ./expected/geometry-powerpc-darwin.out      Mon Dec 11 08:45:16 2000
--- ./results/geometry.out      Tue Oct 29 15:40:56 2002
***************
*** 127,133 ****
!         | (-10,0)    | [(-1000000,200),(300000,-40)] | (-9.99715942258202,15.3864610140472)
--- 127,133 ----
!         | (-10,0)    | [(-1000000,200),(300000,-40)] | (-9.99715942258202,15.3864610140473)
======================================================================

Perhaps the change from gcc2.x to 3.x changed floats a bit?

-pmb

Yes, OSX 10.2.X seems to have this output on _some_ machines, but not
others, and we can't seem to figure out why. Can you tell us more about
your machine and cpu?

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

Peter Bierman wrote:

At 6:11 PM -0500 10/29/02, Neil Conway wrote:

Peter Bierman <bierman@apple.com> writes:

So first off, what's the best way to tell from a cvs snapshot which
"release" (if any) that snapshot is?

configure.in, perhaps?

Ah, thanks. 7.3b3 it is then.

'make runcheck' in src/test/regress/ fails with:

bison -y -d preproc.y
preproc.y:5560: fatal error: maximum table size (32767) exceeded

You need bison 1.50 or greater to build the new ecpg (due to a bison
limitation).

Ok. After upgrading to bison-1.75, all regression tests pass except:

*** ./expected/geometry-powerpc-darwin.out      Mon Dec 11 08:45:16 2000
--- ./results/geometry.out      Tue Oct 29 15:40:56 2002
***************
*** 127,133 ****
!         | (-10,0)    | [(-1000000,200),(300000,-40)] | (-9.99715942258202,15.3864610140472)
--- 127,133 ----
!         | (-10,0)    | [(-1000000,200),(300000,-40)] | (-9.99715942258202,15.3864610140473)
======================================================================

Perhaps the change from gcc2.x to 3.x changed floats a bit?

-pmb

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

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

*** ./expected/geometry-powerpc-darwin.out      Mon Dec 11 08:45:16 2000
--- ./results/geometry.out      Tue Oct 29 15:40:56 2002
***************
*** 127,133 ****
!         | (-10,0)    | [(-1000000,200),(300000,-40)] | (-9.99715942258202,15.3864610140472)
--- 127,133 ----
!         | (-10,0)    | [(-1000000,200),(300000,-40)] | (-9.99715942258202,15.3864610140473)
======================================================================

At 9:19 PM -0500 10/29/02, Bruce Momjian wrote:

Yes, OSX 10.2.X seems to have this output on _some_ machines, but not
others, and we can't seem to figure out why. Can you tell us more about
your machine and cpu?

It's a dual 450MHz G4 with 512MB RAM, running 10.2.1.

Is there any particular type of Mac you'd like me to try it on?

-pmb

Peter Bierman wrote:

*** ./expected/geometry-powerpc-darwin.out      Mon Dec 11 08:45:16 2000
--- ./results/geometry.out      Tue Oct 29 15:40:56 2002
***************
*** 127,133 ****
!         | (-10,0)    | [(-1000000,200),(300000,-40)] | (-9.99715942258202,15.3864610140472)
--- 127,133 ----
!         | (-10,0)    | [(-1000000,200),(300000,-40)] | (-9.99715942258202,15.3864610140473)
======================================================================

At 9:19 PM -0500 10/29/02, Bruce Momjian wrote:

Yes, OSX 10.2.X seems to have this output on _some_ machines, but not
others, and we can't seem to figure out why. Can you tell us more about
your machine and cpu?

It's a dual 450MHz G4 with 512MB RAM, running 10.2.1.

Is there any particular type of Mac you'd like me to try it on?

Yea, one that gets the original value. We know they are out there, but
can't figure out which ones they are. Sorry I can't be more specific.

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

On 29/10/02 6:02 pm, "Tom Lane" <tgl@sss.pgh.pa.us> wrote:

Adam Witney <awitney@sghms.ac.uk> writes:

Just to update the list of supported platforms, 7.3b3 compiles and passes
all the regression tests on MacOSX 10.2.1

Although don't know if this is relevant but this appears when running the
tests:

parallel group (20 tests): ./pg_regress: fork: Resource temporarily
unavailable
./pg_regress: fork: Resource temporarily unavailable
comments lseg box path timetz point circle reltime tinterval date inet
interval timestamp time abstime polygon timestamptz oidjoins

This suggests that you are hitting the per-user limit on the number of
processes you can have; try raising that limit.

I'd expect one of the tests not to have been run when that message
appears; did you really get successful matches for all tests?

regards, tom lane

It appears that my ignorance got the better of me.... It was the first time
I had run the regression tests on any PostgreSQL installation. But I think I
am getting the same problems as others. below is the last part of the
regression tests (I had taken the "All 15 tests passed" as a success!)

Let me know if I can be of any assistance in further checking this out

============== running regression test queries ==============
parallel group (13 tests): char int4 boolean name varchar float8 bit text
int2 oid int8 float4 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): ./pg_regress: fork: Resource temporarily
unavailable
./pg_regress: fork: Resource temporarily unavailable
comments lseg box path timetz point circle reltime tinterval date inet
interval timestamp time abstime polygon timestamptz oidjoins==============
shutting down postmaster ==============

======================
All 15 tests passed.
======================

rm regress.o

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Adam Witney <awitney@sghms.ac.uk> writes:

It appears that my ignorance got the better of me.... It was the first time
I had run the regression tests on any PostgreSQL installation. But I think I
am getting the same problems as others. below is the last part of the
regression tests (I had taken the "All 15 tests passed" as a success!)

No, there should be ~80 tests in all. I'm not sure why the pg_regress
script is failing to process the remaining tests when this happens; any
ideas out there?

regards, tom lane

Peter Bierman <bierman@apple.com> writes:

Ok. After upgrading to bison-1.75, all regression tests pass except:
*** ./expected/geometry-powerpc-darwin.out Mon Dec 11 08:45:16 2000

Perhaps the change from gcc2.x to 3.x changed floats a bit?

Could be. We had previous reports of the same diff on OSX 10.2 with
a G4 processor, so I was wondering if it was hardware or software
differences (geometry-powerpc-darwin.out matches exactly on my G3
laptop running OSX 10.1). I have a 10.2 CD and am planning to update
sometime soon to verify this by experiment. Or, if you can confirm
that you had passes before on the same hardware you're using, we could
conclude that it's the OS update that counts.

In any case, what's the output from config.guess on your machine?

regards, tom lane

Tom Lane writes:

No, there should be ~80 tests in all. I'm not sure why the pg_regress
script is failing to process the remaining tests when this happens; any
ideas out there?

It appears that the shell simply aborts on fork failure. Example:

peter ~$ cat test.sh
ulimit -u 30

for i in $(seq 1 25); do
echo $i
( sleep 5 ) &
echo ok
done

wait
echo "all done"
peter ~$ sh test.sh
1
ok
2
test.sh: fork: Resource temporarily unavailable
peter ~$

In pg_regress, the big loop is probably done in a subshell, because it's
in a pipe, so the outer script can complete. Detecting failures in
commands in a pipe is of course a bit tricky.

--
Peter Eisentraut peter_e@gmx.net

I said:

Peter Bierman <bierman@apple.com> writes:

Perhaps the change from gcc2.x to 3.x changed floats a bit?

Could be. We had previous reports of the same diff on OSX 10.2 with
a G4 processor, so I was wondering if it was hardware or software
differences (geometry-powerpc-darwin.out matches exactly on my G3
laptop running OSX 10.1). I have a 10.2 CD and am planning to update
sometime soon to verify this by experiment.

I have done the update and now I get the "...40473" output on the same
hardware that useta pass. So it's clearly a software-version issue.

Is it worth carrying two expected files for OS X 10.1 and 10.2? I'm
inclined to think not, and am leaning towards updating the expected
file. Comments?

regards, tom lane

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

I said:

Peter Bierman <bierman@apple.com> writes:

Perhaps the change from gcc2.x to 3.x changed floats a bit?

Could be. We had previous reports of the same diff on OSX 10.2 with
a G4 processor, so I was wondering if it was hardware or software
differences (geometry-powerpc-darwin.out matches exactly on my G3
laptop running OSX 10.1). I have a 10.2 CD and am planning to update
sometime soon to verify this by experiment.

I have done the update and now I get the "...40473" output on the same
hardware that useta pass. So it's clearly a software-version issue.

Is it worth carrying two expected files for OS X 10.1 and 10.2? I'm
inclined to think not, and am leaning towards updating the expected
file. Comments?

I'm 90% certain that the difference is caused by GCC 2.95 vs 3.1.
(10.0 & 10.1 vs 10.2)

If you can easily pick the right file based which GCC compiled it, that'd be ideal.

-pmb

Peter Bierman <bierman@apple.com> writes:

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

Is it worth carrying two expected files for OS X 10.1 and 10.2? I'm
inclined to think not, and am leaning towards updating the expected
file. Comments?

I'm 90% certain that the difference is caused by GCC 2.95 vs 3.1.

Probably.

If you can easily pick the right file based which GCC compiled it, that'd be ideal.

No, we can't easily do that. We could conditionalize it on the OS
version, but I don't think it's worth the trouble. I've committed a
change to the expected file so that OSX 10.2 will pass cleanly, and
older versions will have the one-digit difference instead.

This whole issue should go away in PG 7.4, unless someone objects to the
current plan for making float output precision adjustable. We'll back
off the number of displayed digits in the geometry test by one or two
places, and hopefully need only one or a very few geometry comparison
files.

regards, tom lane

At 4:31 PM -0500 11/1/02, Tom Lane wrote:

Peter Bierman <bierman@apple.com> writes:

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

Is it worth carrying two expected files for OS X 10.1 and 10.2? I'm
inclined to think not, and am leaning towards updating the expected
file. Comments?

I'm 90% certain that the difference is caused by GCC 2.95 vs 3.1.

Probably.

I had to do a bunch of updates to my 10.1.x system, but I can now verify that 10.1.5 builds and runs 7.3b3 regression test with no failures.

If you can easily pick the right file based which GCC compiled it, that'd be ideal.

No, we can't easily do that. We could conditionalize it on the OS
version, but I don't think it's worth the trouble. I've committed a
change to the expected file so that OSX 10.2 will pass cleanly, and
older versions will have the one-digit difference instead.

That's fine. If someone gets ambitious, the uname -a from the two differing versions are:

10.1.5
Darwin bierpe3 5.5 Darwin Kernel Version 5.5: Thu May 30 14:51:26 PDT 2002; root:xnu/xnu-201.42.3.obj~1/RELEASE_PPC Power Macintosh powerpc

10.2.1
Darwin cmos.apple.com 6.1 Darwin Kernel Version 6.1: Fri Sep 6 23:24:34 PDT 2002; root:xnu/xnu-344.2.obj~2/RELEASE_PPC Power Macintosh powerpc

This whole issue should go away in PG 7.4, unless someone objects to the
current plan for making float output precision adjustable. We'll back
off the number of displayed digits in the geometry test by one or two
places, and hopefully need only one or a very few geometry comparison
files.

Excellent.

-pmb