Re: cache lookup failed for attribute 1 of relation XXXXXX

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alessandro Aste <alessandro(dot)aste(at)gmail(dot)com>
Cc: pgsql-general(at)postgresql(dot)org, nicola(dot)contu(at)gtt(dot)net
Subject: Re: cache lookup failed for attribute 1 of relation XXXXXX
Date: 2018-07-19 14:41:19
Message-ID: 21687.1532011279@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Alessandro Aste <alessandro(dot)aste(at)gmail(dot)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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Ron 2018-07-19 15:06:28 Re: Is it ok to run vacuum full verbose command for live database for the tables which has more dead tuples?
Previous Message Laurenz Albe 2018-07-19 14:27:32 Re: functions with side effect