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

From: Grzegorz Jaśkiewicz <gryzman(at)gmail(dot)com>
To: Glyn Astill <glynastill(at)yahoo(dot)co(dot)uk>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: 8.3.7, 'cache lookup failed' for a table
Date: 2010-05-12 10:00:13
Message-ID: AANLkTimg00c9t_1As_80RINoUm4dxDdJY7JgZDkSfjci@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Wed, May 12, 2010 at 10:57 AM, Glyn Astill <glynastill(at)yahoo(dot)co(dot)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 dropping it 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 start with "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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Glyn Astill 2010-05-12 10:01:24 Re: 8.3.7, 'cache lookup failed' for a table
Previous Message Grzegorz Jaśkiewicz 2010-05-12 09:57:45 Re: 8.3.7, 'cache lookup failed' for a table