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
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 |