From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | David Clymer <david(dot)clymer(at)vistashare(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Cache lookup failed for relation |
Date: | 2013-02-11 18:22:15 |
Message-ID: | CAFj8pRBVxBfuB+oSomxAhQt0eitiwmQbCYq713Ku+7PSf--CbA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
2013/2/11 David Clymer <david(dot)clymer(at)vistashare(dot)com>
> On Mon, Feb 11, 2013 at 1:13 PM, David Clymer <david(dot)clymer(at)vistashare(dot)com
> > wrote:
>
>> On Mon, Feb 11, 2013 at 12:47 PM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>wrote:
>>
>>> 2013/2/11 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>>> > 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?
>>> >
>>> >> 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
>>>
>>>
> OK, so perhaps the difference is purely due to the use of postgres < 9.2
> on one db.
>
yes, I have not 9.2 now, but on 9.3 you get user friendly message
NOTICE: table "foo" does not exist, skipping
DROP TABLE
Regards
Pavel
>
> -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
>
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2013-02-11 18:50:14 | Re: Cache lookup failed for relation |
Previous Message | David Clymer | 2013-02-11 18:17:58 | Re: Cache lookup failed for relation |