Re: Cache lookup failed for relation

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: David Clymer <david(dot)clymer(at)vistashare(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-general(at)postgresql(dot)org
Subject: Re: Cache lookup failed for relation
Date: 2013-02-11 18:22:15
Message-ID: CAFj8pRBVxBfuB+oSomxAhQt0eitiwmQbCYq713Ku+7PSf--CbA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

2013/2/11 David Clymer <david(dot)clymer(at)vistashare(dot)com>

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

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 <http://www.vistashare.com/>
>
> [image: Facebook] www.facebook.com/vistashare
> [image: Twitter] www.twitter.com/vistashare
>

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Kevin Grittner 2013-02-11 18:50:14 Re: Cache lookup failed for relation
Previous Message David Clymer 2013-02-11 18:17:58 Re: Cache lookup failed for relation