Thread: "gmake check" fails with 8.1.1
Hi,
I don't know what to make of this.
I installed the rpms for 8.1.1 on a RH 4 es system
and did initdb with LC_TYPE=C and LC_COLLATE=C (and
I also tried without changing these locale variables):
cd /usr/lib/pgsql/test
gmake check
gets:
rm -rf ./testtablespace
mkdir ./testtablespace
/bin/sh ./pg_regress --schedule=./parallel_schedule
--multibyte=SQL_ASCII
(using postmaster on Unix socket, default port)
<snip>
triggers ... FAILED
<snip>
transactions ... FAILED
<snip>
plpgsql ... FAILED
copy2 ... FAILED
<snip>
rangefuncs ... FAILED
<snip>
=======================
5 of 98 tests failed.
=======================
So, then I connect to the template1 db and:
template1=# select * from pg_language;
lanname | lanispl | lanpltrusted | lanplcallfoid | lanvalidator |
lanacl
----------+---------+--------------+---------------+--------------+--------
internal | f | f | 0 | 2246 |
c | f | f | 0 | 2247 |
sql | f | t | 0 | 2248 |
(3 rows)
So then:
# su postgres -c 'createlang plpgsql template1'
# su postgres -c 'createlang -l template1'
Procedural Languages
Name | Trusted?
---------+----------
plpgsql | yes
And back in psql:
select * from pg_language;
lanname | lanispl | lanpltrusted | lanplcallfoid | lanvalidator |
lanacl
----------+---------+--------------+---------------+--------------+--------
internal | f | f | 0 | 2246 |
c | f | f | 0 | 2247 |
sql | f | t | 0 | 2248 |
plpgsql | t | t | 38295 | 38296 |
(4 rows)
Restart the server:
# /etc/init.d/postgresql restart
Stopping postgresql service: [ OK ]
Starting postgresql service: [ OK ]
And the problem persists. However, I can make a plpgsql function just
fine and call it without errors in a test database. (Rebuilding
my own rpms from the srpm does not help either.)
What's the problem here and do I need to worry about it?
Thanks.
Karl <kop@meme.com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
Hi, On Thu, 2005-12-15 at 15:24 +0000, Karl O. Pinc wrote: > ======================= > 5 of 98 tests failed. > ======================= regression.diffs for this is at: http://www.gunduz.org/postgresql/regression.diffs I reproduced the same... -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: PL/php, plPerlNG - http://www.commandprompt.com/
Devrim GUNDUZ <devrim@commandprompt.com> writes:
> I reproduced the same...
rpath problem? It would be useful to look at the postmaster log to see
why it's failing to create the language in the 'make check' case.
The other odd thing is, if the createlang step fails, you'd think that
pg_regress would complain about it. Is it possible that createlang
(thinks it) succeeded, but it connected to the wrong database server
or something like that?
regards, tom lane
On 12/15/2005 09:45:12 AM, Tom Lane wrote:
> Devrim GUNDUZ <devrim@commandprompt.com> writes:
> > I reproduced the same...
>
> rpath problem? It would be useful to look at the postmaster log to
> see
> why it's failing to create the language in the 'make check' case.
I don't believe it's just the 'make check' case. Plpgsql is not
in template1 after installation. (If I'm understanding
what you're saying.)
Karl <kop@meme.com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
"Karl O. Pinc" <kop@meme.com> writes:
> I don't believe it's just the 'make check' case. Plpgsql is not
> in template1 after installation.
It's not supposed to be --- at least, not unless you install it there
manually.
Please note also that this is not a generic breakage. What you need to
be asking is what in your particular environment is causing this failure.
I'm inclined to guess that it's specific to "make check"'s temporary
installation. Have you tried "make installcheck" to run against a
non-temp installation?
regards, tom lane
On 12/15/2005 09:55:08 AM, Tom Lane wrote:
> I'm inclined to guess that it's specific to "make check"'s temporary
> installation. Have you tried "make installcheck" to run against a
> non-temp installation?
'make installcheck' gets the same errors (and the same
regression.diffs file (except for the timestamps).)
FWIW, dual Xenon. (Linux sees 4 cpus.)
Karl <kop@meme.com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
Problem solved.
On 12/15/2005 09:55:08 AM, Tom Lane wrote:
> Please note also that this is not a generic breakage. What you need
> to
> be asking is what in your particular environment is causing this
> failure.
The problem is that the rpm substitutes in a Makefile that does not
install the language. If you hack it so that plpgsql is installed
(pg_regress --load-languge=plpgsql ...)
then all the tests pass. (Dunno what's with the rpm's Makefile.
It appears to do a lot of something different.)
Karl <kop@meme.com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
"Karl O. Pinc" <kop@meme.com> writes:
> The problem is that the rpm substitutes in a Makefile that does not
> install the language. If you hack it so that plpgsql is installed
> (pg_regress --load-languge=plpgsql ...)
> then all the tests pass. (Dunno what's with the rpm's Makefile.
> It appears to do a lot of something different.)
Ah-hah. The rpm makefile evidently hasn't tracked changes in the
regular test makefile.
regards, tom lane