2013/2/11 Tom Lane <tgl@sss.pgh.pa.us>:
> David Clymer <david.clymer@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
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@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
