Re: Cache lookup failed for relation

[David Clymer <david.clymer@xxxxxxxxxxxxxx>]

On Mon, Feb 11, 2013 at 12:20 PM, Tom Lane <tgl@xxxxxxxxxxxxx> wrote:

David Clymer <david.clymer@xxxxxxxxxxxxxx> 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?

It appears that almost all instances reference a different OID.

 

> 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?  

Sorry, that's our application level terminology. As far as postgres is concerned they are just individual queries running at the roughly same time.

 

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.)

I don't think we are doing that, but it may be that two queries are attempting to drop the same table "if exists". I'll have to look at that a bit more.

The SERIALIZABLE isolation mode is being used in 9.0, and REPEATABLE READ in 9.2, which should be the same thing, correct (eg. 9.0 serializable ~ 9.2 repeatable read)?

> 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.

Good to know.

-davidc

--
David Clymer
VistaShare
866-828-4782, ext. 828
www.VistaShare.com
 
  www.facebook.com/vistashare
  www.twitter.com/vistashare