Re: 8.3.7, 'cache lookup failed' for a table

Поиск
Список
Период
Сортировка
От Grzegorz Jaśkiewicz
Тема Re: 8.3.7, 'cache lookup failed' for a table
Дата
Msg-id AANLkTimg00c9t_1As_80RINoUm4dxDdJY7JgZDkSfjci@mail.gmail.com
обсуждение исходный текст
Ответ на Re: 8.3.7, 'cache lookup failed' for a table  (Glyn Astill <glynastill@yahoo.co.uk>)
Ответы Re: 8.3.7, 'cache lookup failed' for a table  (Glyn Astill <glynastill@yahoo.co.uk>)
Список pgsql-general
On Wed, May 12, 2010 at 10:57 AM, Glyn Astill <glynastill@yahoo.co.uk> wrote:
> Hi Grzegorz,
>
> Is it always the same OID(s)?
>
> Usually this means something somewhere has a link to an OID that has been removed.
>
> You could try digging through pg_catalog lookng for an oid column that refers to the OID in question.
>
> In my experience, when a slony 1.2.x slave is involved, this usually means a relation was dropped without first
droppingit from replication using DROP TABLE.  In this case it may be a trigger on a table that has been "disabled" by
slony,it does this by changing pg_trigger.tgrelid to point to an index on the table in question rather than the table
itself. Thus when the table is dropped the trigger is left behind, pointing to an index that isn't there.  I' probably
startwith "select * from "pg_catalog".pg_trigger where tgrelid = <the OID that doesn't exist>", and prune from there. 

It only happened to me once.
You think it is because slony is poking around pg_catalog. schema, and
it shouldn't , basically ?

--
GJ

В списке pgsql-general по дате отправления:

Предыдущее
От: Grzegorz Jaśkiewicz
Дата:
Сообщение: Re: 8.3.7, 'cache lookup failed' for a table
Следующее
От: Glyn Astill
Дата:
Сообщение: Re: 8.3.7, 'cache lookup failed' for a table