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
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 |
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 |