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