On Mon, Feb 11, 2013 at 12:20 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> 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? > It appears that almost all instances reference a different OID. > > > 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? Sorry, that's our application level terminology. As far as postgres is concerned they are just individual queries running at the roughly same time. > 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.) > I don't think we are doing that, but it may be that two queries are attempting to drop the same table "if exists". I'll have to look at that a bit more. The SERIALIZABLE isolation mode is being used in 9.0, and REPEATABLE READ in 9.2, which should be the same thing, correct (eg. 9.0 serializable ~ 9.2 repeatable read)? > > One other item of note: db #2 has recently had an OID wrap-around, which > > makes me suspect that plays some part in this behavior. > > I don't believe that theory at all. > Good to know. -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
