Re: Cache lookup failed for relation

[Pavel Stehule <pavel.stehule@xxxxxxxxx>]

2013/2/11 David Clymer <david.clymer@xxxxxxxxxxxxxx>

On Mon, Feb 11, 2013 at 1:13 PM, David Clymer <david.clymer@xxxxxxxxxxxxxx> wrote:

On Mon, Feb 11, 2013 at 12:47 PM, Pavel Stehule <pavel.stehule@xxxxxxxxx> wrote:

2013/2/11 Tom Lane <tgl@xxxxxxxxxxxxx>:

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

we can see same behave in 9.1

when you try drop some tables in parallel sessions

 

OK, so perhaps the difference is purely due to the use of postgres < 9.2 on one db.

yes, I have not 9.2 now, but on 9.3 you get user friendly message

NOTICE:  table "foo" does not exist, skipping
DROP TABLE

Regards

Pavel
 

-davidc

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