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. Glyn --- On Wed, 12/5/10, Grzegorz Jaśkiewicz <gryzman@xxxxxxxxx> wrote: > From: Grzegorz Jaśkiewicz <gryzman@xxxxxxxxx> > Subject: Re: 8.3.7, 'cache lookup failed' for a table > To: pgsql-general@xxxxxxxxxxxxxx > Date: Wednesday, 12 May, 2010, 10:33 > anyone please ? > > -- > Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general > -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
