Re: Cache lookup failed for relation

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: David Clymer <david(dot)clymer(at)vistashare(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Cache lookup failed for relation
Date: 2013-02-11 17:20:33
Message-ID: 23027.1360603233@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

David Clymer <david(dot)clymer(at)vistashare(dot)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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Pavel Stehule 2013-02-11 17:47:03 Re: Cache lookup failed for relation
Previous Message David Clymer 2013-02-11 17:09:19 Cache lookup failed for relation