Обсуждение: 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