On Mon, Feb 11, 2013 at 12:20 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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?
>
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
