From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Laurent FAILLIE <l_faillie(at)yahoo(dot)com> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: Bug #608: cache lookup failed |
Date: | 2002-03-07 15:05:42 |
Message-ID: | 9894.1015513542@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
=?iso-8859-1?q?Laurent=20FAILLIE?= <l_faillie(at)yahoo(dot)com> writes:
> scheduling=# select * from pg_proc where
> proname='plpgsql_call_handler';
> proname | proowner | prolang | proisinh
> | proistrusted | proiscachable | proisstrict |
> pronargs | proretset | prorettype | proargtypes |
> probyte_pct | pro
> perbyte_cpu | propercall_cpu | prooutin_ratio |
> prosrc | probin
> ----------------------+----------+---------+----------+--------------+---------------+-------------+----------+-----------+------------+-------------+-------------+----
> ------------+----------------+----------------+----------------------+---------------------------------
> plpgsql_call_handler | 1 | 13 | f
> | t | f | f |
> 0 | f | 0 | | 100
> |
> 0 | 0 | 100 |
> plpgsql_call_handler | /usr/local/pgsql/lib/plpgsql.sl
Well, that looks reasonable, but what's its OID? (should've asked for
select oid,* from ...)
The easiest way to get back to a working database is to UPDATE the
pg_language row with the correct OID of the call handler function.
I'd be interested to know how you got into this state, though.
I have to think that you dropped and recreated the handler function
without going through the full 'droplang'/'createlang' cycle.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Stephan Szabo | 2002-03-07 15:44:24 | Re: regression - postgresql 7.2 on power pc/linux |
Previous Message | Laurent FAILLIE | 2002-03-07 10:47:08 | Re: Bug #608: cache lookup failed |