Re: Bug #608: cache lookup failed

Поиск
Список
Период
Сортировка
Искать
От
Tom Lane
Тема
Re: Bug #608: cache lookup failed
Дата
Msg-id
9894.1015513542@sss.pgh.pa.us
Ответ на
Список
Дерево обсуждения
Re: Bug #608: cache lookup failed Laurent FAILLIE <l_faillie@yahoo.com>
Laurent FAILLIE  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

В списке pgsql-bugs по дате отправления
От: Arkadiusz Miskiewicz
Дата:
От: Tom Lane
Дата:
FAQ