Re: "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(at)meme(dot)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(at)commandprompt(dot)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

"Karl O. Pinc" <kop(at)meme(dot)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:45:12 AM, Tom Lane wrote:
> Devrim GUNDUZ <devrim(at)commandprompt(dot)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(at)meme(dot)com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein

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(at)meme(dot)com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein

"Karl O. Pinc" <kop(at)meme(dot)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

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(at)meme(dot)com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein