Re: Cache lookup failed for relation

From: David Clymer <david(dot)clymer(at)vistashare(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Cache lookup failed for relation
Date: 2013-02-11 18:11:29
Message-ID: CAKDVv34DjwV+rbUbdkWCfbn8DqxyL+nztCARcC6SgJxZ3PNS4A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Mon, Feb 11, 2013 at 12:20 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> David Clymer <david(dot)clymer(at)vistashare(dot)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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message David Clymer 2013-02-11 18:13:01 Re: Cache lookup failed for relation
Previous Message Wolfgang Keller 2013-02-11 18:02:35 Re: Visual query builder for PosgreSQL?