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