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, -- *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
