Re: Cache lookup failed for relation - Mailing list pgsql-general

From Tom Lane
Subject Re: Cache lookup failed for relation
Date
Msg-id 23027.1360603233@sss.pgh.pa.us
Whole thread Raw
In response to Cache lookup failed for relation  (David Clymer <david.clymer@vistashare.com>)
Responses Re: Cache lookup failed for relation  (Péter Kovács <peter.dunay.kovacs@gmail.com>)
Re: Cache lookup failed for relation  (Pavel Stehule <pavel.stehule@gmail.com>)
Re: Cache lookup failed for relation  (David Clymer <david.clymer@vistashare.com>)
List pgsql-general
David Clymer <david.clymer@vistashare.com> writes:
> I've been seeing the following error in one database of ours:
>   "cache lookup failed for relation 7640518"

Always the same OID, or does it change?

> The SQL that apparently triggers this is:
>    drop table if exists ns_e5461ae570429d0b7863cce9ef4d4ead;

> Unfortunately, manual attempts to reproduce the issue have failed. In
> normal operation, this statement is run as one of several parallel queries,
> and the tables are by nature, short lived. That said, they are not
> temporary tables.

Hm ... what are the parallel queries exactly?  If you're doing something
like dropping both ends of a foreign-key linkage in parallel, I'd not be
very astonished by an error like this, especially not in 9.0.x.  It'd be
basically a race condition between two sessions both locking the same
table, but by the time the second one gets the lock, the first one has
dropped the table.  (Robert Haas has done some great work towards
eliminating this type of race condition lately, but it's sure not in
9.0.x.)

> One other item of note: db #2 has recently had an OID wrap-around, which
> makes me suspect that plays some part in this behavior.

I don't believe that theory at all.

            regards, tom lane

pgsql-general by date:

Previous
From: David Clymer
Date:
Subject: Cache lookup failed for relation
Next
From: Péter Kovács
Date:
Subject: Re: Cache lookup failed for relation