Re: Cache lookup failed for relation

On Mon, Feb 11, 2013 at 1:13 PM, David Clymer
<david(dot)clymer(at)vistashare(dot)com>wrote:

> On Mon, Feb 11, 2013 at 12:47 PM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>wrote:
>
>> 2013/2/11 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>> > 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.)
>>
>> 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.

-davidc

--
*David Clymer*
VistaShare
866-828-4782, ext. 828
www.VistaShare.com <http://www.vistashare.com/>

[image: Facebook] www.facebook.com/vistashare
[image: Twitter] www.twitter.com/vistashare