Thread
-
runtest bug and bigcheck problems
Rick Touchette <rick.touchette@nwa.com> — 2001-04-06T18:25:27Z
Some background: Version: postgresql-7.0.3 installed in nonstandard location (/home/nssrta/pgsql) OS: Solaris 2.6 (patch level unknown, but definitely not current) Running under the installed user id Item #1 Bug in runtest: In order to get the runtest regression test to work I had to change line 100 in regress.sh from: createlang $HOSTLOC plpgsql regression to: createlang -L /home/n33rta/pgsql/lib $HOSTLOC plpgsql regression (I had to specify the lib location) There should be a way to get this value from the Makefile.global which is included in the GNUmakefile, But GNUmakefile is running regress.sh in a shell. Sorry, I'm not very knowledgeable with gmake and therefore I haven't a eloquent solution to suggest. Item #2 Before install the runcheck test worked fine but when I tried the bigcheck test it hung. that is the test ran fine until the big (whatever) test and never finished (4+ hours) I did notice a defunct process from which had a common parent to the postmaster process. Any ideas?? Thanks, Rick Touchette -
Re: runtest bug and bigcheck problems
Tom Lane <tgl@sss.pgh.pa.us> — 2001-04-13T16:06:26Z
"Rick Touchette" <rick.touchette@nwa.com> writes: > In order to get the runtest regression test to work I had to change line 100 > in regress.sh > from: > createlang $HOSTLOC plpgsql regression > to: > createlang -L /home/n33rta/pgsql/lib $HOSTLOC plpgsql regression > (I had to specify the lib location) This is fixed in 7.1. > Item #2 > Before install the runcheck test worked fine but when I tried the bigcheck > test it hung. > that is the test ran fine until the big (whatever) test and never finished > (4+ hours) If you got through the regular test then it's highly unlikely that bigcheck would really fail --- it's simply a repeat of the regular numeric test with (many) more digit positions. I think you just didn't wait long enough. The big numeric test does take a ridiculously long time... regards, tom lane