Re: Bug #608: cache lookup failed

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

In response to

Responses

Browse pgsql-bugs by date

  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