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

--- On Wed, 12/5/10, Grzegorz Jaśkiewicz <gryzman(at)gmail(dot)com> wrote:
> 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 ?
>

No, Slony 1.2.x pokes around in pg_catalog because in versions of postgres prior to 8.3 (which 1.2.x has to support) there was no built in way to disable the triggers. So it's not that it slony shouldn't be poking around there, it's that if you choose to use slony you should make sure you drop the relation from replication before dropping it - else you'll make a mess.