Thread: 7.3b3 on MacOSX 10.2.1
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 unavailablecomments 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.
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, Pennsylvania19073
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 dualCPU 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, Pennsylvania19073
>> *** ./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, Pennsylvania19073
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 unavailablecomments 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 testwith 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 PowerMacintosh 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