On Mon, Feb 11, 2013 at 12:47 PM, Pavel Stehule <pavel.stehule@gmail.com>wrote:
> 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
>
>
OK,
--
*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
