Re: Re: backend dies on 7.1.1 loading large datamodel.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Hentosh <hentosh(at)io(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: Re: backend dies on 7.1.1 loading large datamodel.
Date: 2001-05-08 00:28:33
Message-ID: 24360.989281713@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

Robert Hentosh <hentosh(at)io(dot)com> writes:
> I just put the datamodel at http://www.io.com/~hentosh/sql.tar.gz

Hm. I notice that postgres.sql hardwires the location of the plpgsql
handler:

create function plpgsql_call_handler() RETURNS opaque
as '/usr/local/pgsql/lib/plpgsql.so' language 'c';

create trusted procedural language 'plpgsql'
HANDLER plpgsql_call_handler
LANCOMPILER 'PL/pgSQL';

If this were to suck in a wrong-version copy of plpgsql.so (and yes,
I think 7.1 vs 7.1.1 could be wrong version) then that could cause
failures.

postgres-pgtcl.sql is equally unwise about the pltcl handler.

This is *not* the source of your problem, since I was able to
reproduce the crash even with a proper "createlang plpgsql" used
instead of the bogus commands. But you might want to pass on the
observation to the OpenACS guys.

On with debugging ...

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Bruce Momjian 2001-05-08 00:28:58 Re: RAISE concatination/variables in plpgsql
Previous Message Tom Lane 2001-05-08 00:15:22 Re: RAISE concatination/variables in plpgsql

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2001-05-08 00:54:14 Re: backend dies on 7.1.1 loading large datamodel.
Previous Message Bruce Momjian 2001-05-08 00:19:04 Re: System catalog representation of access privileges