2013/2/11 Tom Lane <tgl@xxxxxxxxxxxxx>: > David Clymer <david.clymer@xxxxxxxxxxxxxx> 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 Regards Pavel Stehule > >> 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. > > regards, tom lane > > > -- > Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
