Alessandro Aste <alessandro.aste@gmail.com> writes:
> pg_dump: [archiver (db)] query failed: ERROR: cache lookup failed for
> attribute 1 of relation 2223152859
> pg_dump: [archiver (db)] query was: SELECT t.tableoid, t.oid, t.relname
> AS indexname, pg_catalog.pg_get_indexdef(i.indexrelid) AS indexdef,
> t.relnatts AS indnkeys, i.indkey, i.indisclustered, i.indisreplident,
> t.relpages, c.contype, c.conname, c.condeferrable, c.condeferred,
> c.tableoid AS contableoid, c.oid AS conoid,
> pg_catalog.pg_get_constraintdef(c.oid, false) AS condef, (SELECT spcname
> FROM pg_catalog.pg_tablespace s WHERE s.oid = t.reltablespace) AS
> tablespace, t.reloptions AS indreloptions FROM pg_catalog.pg_index i JOIN
> pg_catalog.pg_class t ON (t.oid = i.indexrelid) LEFT JOIN
> pg_catalog.pg_constraint c ON (i.indrelid = c.conrelid AND i.indexrelid =
> c.conindid AND c.contype IN ('p','u','x')) WHERE i.indrelid =
> '2223152859'::pg_catalog.oid AND i.indisvalid AND i.indisready ORDER BY
> indexname
Hmm ...
> Index with that indexrelid does not exists
> SELECT * FROM pg_catalog.pg_index WHERE indexrelid = '2223152859';
> (0 rows)
You sure? The failed query was looking for indrelid not indexrelid.
That implies that 2223152859 is/was the table not the index. In
any case it'd be better to look for that OID in pg_class.
If that table is in fact gone, one possible theory is that it was
dropped concurrently with the pg_dump run. Then possibly
pg_get_indexdef() would see the table as already gone when the
surrounding query had found it in the catalogs, which could easily
result in the reported error. However, pg_dump shouldn't be poking
into the indexes of a table that it doesn't have AccessShareLock on,
so I'm not quite sure how we could end up with this result. Maybe
the true explanation is more complicated, like an ALTER DROP COLUMN
that committed just as pg_dump was starting. Have you got records
of any DDL being done at that time?
regards, tom lane