2013/2/11 David Clymer <david.clymer@vistashare.com>
> On Mon, Feb 11, 2013 at 1:13 PM, David Clymer <david.clymer@vistashare.com
> > wrote:
>
>> On Mon, Feb 11, 2013 at 12:47 PM, Pavel Stehule <pavel.stehule@gmail.com>wrote:
>>
>>> 2013/2/11 Tom Lane <tgl@sss.pgh.pa.us>:
>>> > David Clymer <david.clymer@vistashare.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
>
