Обсуждение: fedora core 2 postgresql regression tests fail
Hello, I have been playing with postgresql at home, working through a book on general database installation and use. Mostly it is an oracle book, but much of the book is easily translated to Postgres. This is on a fedora core 2 linux box, kept fully yum updated. Here are the packages installed via yum: $ rpm -qa | grep postgres postgresql-libs-7.4.2-1 postgresql-server-7.4.2-1 postgresql-test-7.4.2-1 postgresql-7.4.2-1 postgresql-devel-7.4.2-1 Then I enable plpgsql: $ droplang plpgsql template1 $ createlang plpgsql template1 $ createlang -l template1 Procedural Languages Name | Trusted? ---------+---------- plpgsql | yes As user postgres I try and run the tests: $ pwd /usr/lib/pgsql/test/regress $ time ./pg_regress.sh --schedule=parallel_schedule ... ==================================================== 6 of 93 tests failed, 1 of these failures ignored. ==================================================== ... $ grep -i FAIL ./regression.out test create_function_1 ... FAILED triggers ... FAILED plpgsql ... failed (ignored) copy2 ... FAILED rangefuncs ... FAILED test stats ... FAILED Here are some results from the diffs: $ grep ERROR regression.diffs ERROR: could not access file "nosuchfile": No such file or directory ! ERROR: Can't find function nosuchsymbol in file /usr/lib/pgsql/test/regress/regress.so ERROR: there is no built-in function named "nosuch" ERROR: could not access file "nosuchfile": No such file or directory ! ERROR: could not find function "nosuchsymbol" in file "/usr/lib/pgsql/test/regress/regress.so" ERROR: there is no built-in function named "nosuch" + ERROR: language "plpgsql" does not exist + ERROR: function trigger_func() does not exist + ERROR: function trigger_func() does not exist + ERROR: function trigger_func() does not exist + ERROR: function trigger_func() does not exist + ERROR: language "plpgsql" does not exist ... $ grep plpgsql regression.diffs | more + ERROR: language "plpgsql" does not exist *** ./expected/plpgsql.out Wed Sep 24 23:58:06 2003 --- ./results/plpgsql.out Mon Sep 27 21:11:32 2004 ' language 'plpgsql'; + ERROR: language "plpgsql" does not exist ... $ grep HINT regression.diffs + HINT: You need to use "createlang" to load the language into the database. ... So I guess I am confused. I thought I added the required language (plpgsql) properly. Sorry if this is something obvious, I have googled several times and have not found much help for this. Perhaps I should be building from source or using the RedHat "rhdb" iso? Thanks for any hints, John
John McBride wrote: > Hello, > > I have been playing with postgresql at home, working through a book on > general database installation and use. Mostly it is an oracle book, but > much of the book is easily translated to Postgres. This is on a fedora > core 2 linux box, kept fully yum updated. > > Here are the packages installed via yum: > > $ rpm -qa | grep postgres > postgresql-libs-7.4.2-1 > postgresql-server-7.4.2-1 > postgresql-test-7.4.2-1 > postgresql-7.4.2-1 > postgresql-devel-7.4.2-1 > > Then I enable plpgsql: > > $ droplang plpgsql template1 > $ createlang plpgsql template1 > $ createlang -l template1 > Procedural Languages > Name | Trusted? > ---------+---------- > plpgsql | yes > > As user postgres I try and run the tests: > > $ pwd > /usr/lib/pgsql/test/regress > $ time ./pg_regress.sh --schedule=parallel_schedule > .... > ==================================================== > 6 of 93 tests failed, 1 of these failures ignored. > ==================================================== > .... > > $ grep -i FAIL ./regression.out > test create_function_1 ... FAILED > triggers ... FAILED > plpgsql ... failed (ignored) > copy2 ... FAILED > rangefuncs ... FAILED > test stats ... FAILED > > Here are some results from the diffs: > > $ grep ERROR regression.diffs > ERROR: could not access file "nosuchfile": No such file or directory > ! ERROR: Can't find function nosuchsymbol in file > /usr/lib/pgsql/test/regress/regress.so > ERROR: there is no built-in function named "nosuch" > ERROR: could not access file "nosuchfile": No such file or directory > ! ERROR: could not find function "nosuchsymbol" in file > "/usr/lib/pgsql/test/regress/regress.so" > ERROR: there is no built-in function named "nosuch" > + ERROR: language "plpgsql" does not exist > + ERROR: function trigger_func() does not exist > + ERROR: function trigger_func() does not exist > + ERROR: function trigger_func() does not exist > + ERROR: function trigger_func() does not exist > + ERROR: language "plpgsql" does not exist > .... > > $ grep plpgsql regression.diffs | more > + ERROR: language "plpgsql" does not exist > *** ./expected/plpgsql.out Wed Sep 24 23:58:06 2003 > --- ./results/plpgsql.out Mon Sep 27 21:11:32 2004 > ' language 'plpgsql'; > + ERROR: language "plpgsql" does not exist > .... > > $ grep HINT regression.diffs > + HINT: You need to use "createlang" to load the language into the > database. > .... > > So I guess I am confused. I thought I added the required language > (plpgsql) properly. Sorry if this is something obvious, I have googled > several times and have not found much help for this. > > Perhaps I should be building from source or using the RedHat "rhdb" iso? > > Thanks for any hints, > John > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faqs/FAQ.html > might or might not help for your test, there is a 7.4.5 version for fedora core 2. you can find it on any of the mirrors, for example: ftp://ftp7.de.postgresql.org/pub/ftp.postgresql.org/binary/v7.4.5/rpms/fedora/fedora-core-2
stig erikson wrote: > John McBride wrote: > >> >> As user postgres I try and run the tests: >> >> $ pwd >> /usr/lib/pgsql/test/regress >> $ time ./pg_regress.sh --schedule=parallel_schedule >> .... >> ==================================================== >> 6 of 93 tests failed, 1 of these failures ignored. >> ==================================================== > > might or might not help for your test, there is a 7.4.5 version for > fedora core 2. > > you can find it on any of the mirrors, for example: > ftp://ftp7.de.postgresql.org/pub/ftp.postgresql.org/binary/v7.4.5/rpms/fedora/fedora-core-2 > I forgot to mention something. It looks like the tests are setup for people who install from source, not rpm. The README file says to run "gmake check" to run the regression tests; if I do that I get: $ gmake check GNUmakefile:16: ../../../src/Makefile.global: No such file or directory gmake: *** No rule to make target `../../../src/Makefile.global'. Stop. So I look at the makefile and try to run the command myself (I have seen from google that some other people do this, too) : $ time ./pg_regress.sh --schedule=parallel_schedule -bash: ./pg_regress.sh: Permission denied real 0m0.006s user 0m0.000s sys 0m0.002s $ chmod +x ./pg_regress.sh $ time ./pg_regress.sh --schedule=parallel_schedule(using postmaster on Unix socket, default port) ============== dropping database "regression" ============== ./pg_regress.sh: line 450: @bindir@/dropdb: No such file or directory ============== creating database "regression" ============== ./pg_regress.sh: line 490: @bindir@/createdb: No such file or directory pg_regress.sh: createdb failed real 0m1.404s user 0m0.093s sys 0m0.195s Now I change the variable @bindir@ in the script to /usr/bin and try again, getting the results of my previous email: ==================================================== 6 of 93 tests failed, 1 of these failures ignored. ==================================================== (random sometimes fails too but I know about that from the docs). It is now obvious to me that these failures are probably caused by the remaining uninitialized variables in pg_regress.sh (if this was a source build/install "gmake check" would successfully run and "sed" the variables in the script for me). I don't know how to set these: pg_regress: pg_regress.sh GNUmakefile sed -e 's,@bindir@,$(bindir),g' \ -e 's,@libdir@,$(libdir),g' \ -e 's,@pkglibdir@,$(pkglibdir),g' \ -e 's,@datadir@,$(datadir),g' \ -e 's/@VERSION@/$(VERSION)/g' \ -e 's/@host_tuple@/$(host_tuple)/g' \ -e 's,@GMAKE@,$(MAKE),g' \ -e 's/@enable_shared@/$(enable_shared)/g' \ -e 's/@GCC@/$(GCC)/g' \ $< >$@ chmod a+x $@ --- John
stig erikson wrote: > John McBride wrote: > >> >> As user postgres I try and run the tests: >> >> $ pwd >> /usr/lib/pgsql/test/regress >> $ time ./pg_regress.sh --schedule=parallel_schedule Okay, some of these problems are my fault. The README file in the test directory clearly states to run the tests via "gmake check": $ gmake check GNUmakefile:16: ../../../src/Makefile.global: No such file or directory gmake: *** No rule to make target `../../../src/Makefile.global'. Stop. So I look in the makefile to see how the tests should be run. I did not realize that a sed operation updates some variables in the script prior to running the tests. So I try to run the tests by hand, after doing a chmod +x on the script: $ time ./pg_regress.sh --schedule=parallel_schedule (using postmaster on Unix socket, default port) ============== dropping database "regression" ============== ./pg_regress.sh: line 449: @bindir@/dropdb: No such file or directory ============== creating database "regression" ============== ./pg_regress.sh: line 489: @bindir@/createdb: No such file or directory pg_regress.sh: createdb failed real 0m0.426s user 0m0.088s sys 0m0.184s If I change "@bindir@" (below) to /usr/bin it runs with the same errors I listed previously, whether I use the new rpms stig suggested or not. I bet the other unset variables are causing the failures: libdir='@libdir@' pkglibdir='/usr/lib/pgsql' # bindir='@bindir@' bindir='/usr/bin' datadir='@datadir@' host_platform='@host_tuple@' enable_shared='@enable_shared@' I've no idea what the others should be set to. I think the tests directory is setup for people who install from source, rather than binary installers. --- John
John McBride wrote: > stig erikson wrote: > >> John McBride wrote: >> >>> >>> As user postgres I try and run the tests: >>> >>> $ pwd >>> /usr/lib/pgsql/test/regress >>> $ time ./pg_regress.sh --schedule=parallel_schedule > > I've no idea what the others should be set to. I think the tests > directory is setup for people who install from source, rather than > binary installers. > This is most certainly the problem. It looks like the "tests" rpm depends on the source code being present to run, and it is not there. I downloaded/built/installed 8b3 and here is the result: ====================== All 96 tests passed. ====================== The variables for a build/install end up as: bindir=/usr/local/pgsql/bin libdir=/usr/local/pgsql/lib pkglibdir=/usr/local/pgsql/lib datadir=/usr/local/pgsql/share VERSION=8.0.0beta3 host_tuple= GMAKE=gmake enable_shared=yes GCC=yes Next I removed 8b3 and reinstalled 7.4.2, added the following set to the pg_regress.sh: bindir=/usr/bin libdir=/usr/lib/pgsql pkglibdir=/usr/lib/pgsql datadir=/var/lib/pgsql VERSION=7.4.2 host_tuple= GMAKE=gmake enable_shared=yes GCC=yes Now it is down to one error: test create_function_1 ... FAILED ======================= 1 of 93 tests failed. ======================= $ cat ./regression.diffs *** ./expected/create_function_1.out Wed Mar 10 13:36:51 2004 --- ./results/create_function_1.out Sat Oct 2 15:20:50 2004 *************** *** 70,76 **** ERROR: could not access file "nosuchfile": No such file or directory CREATE FUNCTION test1 (int) RETURNS int LANGUAGE c AS '/usr/lib/pgsql/test/regress/regress.so', 'nosuchsymbol'; ! ERROR: Can't find function nosuchsymbol in file /usr/lib/pgsql/test/regress/regress.so CREATE FUNCTION test1 (int) RETURNS int LANGUAGE internal AS 'nosuch'; ERROR: there is no built-in function named "nosuch" --- 70,76 ---- ERROR: could not access file "nosuchfile": No such file or directory CREATE FUNCTION test1 (int) RETURNS int LANGUAGE c AS '/usr/lib/pgsql/test/regress/regress.so', 'nosuchsymbol'; ! ERROR: could not find function "nosuchsymbol" in file "/usr/lib/pgsql/test/regress/regress.so" CREATE FUNCTION test1 (int) RETURNS int LANGUAGE internal AS 'nosuch'; ERROR: there is no built-in function named "nosuch" ====================================================================== PS sorry about the double post earlier. The first did not show up in my sent items and the list slowed down temporarily and I did not notice in time--I thought the first msg was lost.
On Thursday 30 September 2004 00:07, John McBride wrote: > As user postgres I try and run the tests: > $ pwd > /usr/lib/pgsql/test/regress > $ time ./pg_regress.sh --schedule=parallel_schedule > ==================================================== > 6 of 93 tests failed, 1 of these failures ignored. > ==================================================== My aplogies for the delay, I have been very busy and have not up until a few minutes ago been able to attempt to reproduce your problems. I can't reproduce some of your problems. When running the tests in the RPM way (see README.rpm-dist in /usr/share/docs/postgresql-7.4.2) (note that you do NOT need to separately creatlang plpgsql, since the regression script does that for you): bash-2.05b$ ./pg_regress --schedule=parallel_schedule (using postmaster on Unix socket, default port) ============== dropping database "regression" ============== dropdb: database removal failed: ERROR: database "regression" does not exist ============== creating database "regression" ============== CREATE DATABASE ALTER DATABASE ============== dropping regression test user accounts ============== ============== installing PL/pgSQL ============== ============== running regression test queries ============== parallel group (13 tests): boolean int4 float8 int2 char int8 text name varchar oid bit float4 numeric [snip] parallel group (20 tests): point lseg time date timetz timestamp reltime intervaltimestamptz tinterval inet path box abstime circle polygon comments type_sanity oidjoins opr_sanity [snip] test create_function_1 ... FAILED [snip] parallel group (17 tests): select_into select_distinct select_implicit select_having select_distinct_on case aggregates portals union btree_index random hash_index update transactions join arrays subselect [snip] random ... failed (ignored) [snip] ==================================================== 2 of 93 tests failed, 1 of these failures ignored. ==================================================== =======regression.diffs============ *** ./expected/create_function_1.out Wed Mar 10 16:36:51 2004 --- ./results/create_function_1.out Mon Oct 4 13:44:19 2004 *************** *** 70,76 **** ERROR: could not access file "nosuchfile": No such file or directory CREATE FUNCTION test1 (int) RETURNS int LANGUAGE c AS '/usr/lib/pgsql/test/regress/regress.so', 'nosuchsymbol'; ! ERROR: Can't find function nosuchsymbol in file /usr/lib/pgsql/test/regress/regr ess.so CREATE FUNCTION test1 (int) RETURNS int LANGUAGE internal AS 'nosuch'; ERROR: there is no built-in function named "nosuch" --- 70,76 ---- ERROR: could not access file "nosuchfile": No such file or directory CREATE FUNCTION test1 (int) RETURNS int LANGUAGE c AS '/usr/lib/pgsql/test/regress/regress.so', 'nosuchsymbol'; ! ERROR: could not find function "nosuchsymbol" in file "/usr/lib/pgsql/test/regre ss/regress.so" CREATE FUNCTION test1 (int) RETURNS int LANGUAGE internal AS 'nosuch'; ERROR: there is no built-in function named "nosuch" ====================================================================== *** ./expected/random.out Thu Feb 13 00:24:04 2003 --- ./results/random.out Mon Oct 4 13:44:45 2004 *************** *** 31,35 **** WHERE random NOT BETWEEN 80 AND 120; random -------- ! (0 rows) --- 31,36 ---- WHERE random NOT BETWEEN 80 AND 120; random -------- ! 73 ! (1 row) =============== Now, if you'll look very carefully the create_funtion_1 failure is due to the difference between the expected output: Can't find function nosuchsymbol and the generated output: could not find function "nosuchsymbol" This is not a problem, since it's just a different wording. The test is checking to make sure that it can reliably fail an attempt to create a nonexistent funtion. Minor differences in error message wording often causes the regression test suite to trip up on trivial things, like this one. The random test fails randomly anyway; random can present a result not between 80 and 120 on occasion. It is _SUPPOSED_ to fail in a random manner. My box is Fedora Core 2, fully updated, with a few third party RPM's loaded, but none of which should change the PostgreSQL results. Now, since I am the one responsible for the regression tests being present in the RPMset, let me make note that the instructions on the from-source RECOMMENDED manner of running the regression tests DO NOT WORK in the RPM installation, and never have. Instead of invoking pg_regress.sh, invoke pg_regress directly, as I did above. The initial variable substitutions that the from-source make does I already have done in the building process. So, in my case, the regression tests PASS, since the two failures aren't really failures. This is better than previous versions, where failures were expected due to libc difficulties, locale problems, etc. Things are much better now. The regression tests have been bundled in the RPMset since 6.5.2 days (five years ago). They have never been terribly reliable in the RPM installation, but my primary intention in packaging them (which has been contested before) was so that they were available without the source. They can (and do) run without a source tree installed, but it isn't an easy thing, and you do have to investigate the failures very carefully. It is just recently that Red Hat/Fedora Project has pulled through the -test subpackage into their distribution; previously it was not built by them (disabled in the spec file) due to space constraints and the potential for confusion. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu
Lamar Owen wrote: > On Thursday 30 September 2004 00:07, John McBride wrote: > >>As user postgres I try and run the tests: > > >>$ pwd >>/usr/lib/pgsql/test/regress >>$ time ./pg_regress.sh --schedule=parallel_schedule [snip] > =============== > Now, if you'll look very carefully the create_funtion_1 failure is due to the > difference between the expected output: > Can't find function nosuchsymbol > and the generated output: > could not find function "nosuchsymbol" > > This is not a problem, since it's just a different wording. The test is > checking to make sure that it can reliably fail an attempt to create a > nonexistent funtion. Minor differences in error message wording often causes > the regression test suite to trip up on trivial things, like this one. my later message drops the error count to one, too. btw, i never claimed that "random" failures were an issue; it was never one of the six i mentioned. as far as the string difference issue causing the create_function_1 failure, that's good news--it's the only one i couldn't figure out. create_function_1 does not fail when 8b3 is built from source so i think the pg crew has somehow corrected the error. and i am sorry for not reading the share docs. all i read was the README in the regress directory and a few notes i found on the web. thank you, John