Received: from maia.hub.org (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id DCD7E633731 for ; Sat, 3 Apr 2010 23:50:25 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 29763-07 for ; Sun, 4 Apr 2010 02:50:14 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-pz0-f176.google.com (mail-pz0-f176.google.com [209.85.222.176]) by mail.postgresql.org (Postfix) with ESMTP id 4BF85633270 for ; Sat, 3 Apr 2010 23:50:15 -0300 (ADT) Received: by pzk6 with SMTP id 6so305238pzk.1 for ; Sat, 03 Apr 2010 19:50:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=t//YV4ZbB6gV2CRX9RzBiC7KYdACAi9isJZRqtqTh9k=; b=hBwZVik3wCMmw7teHtxLJLvJLF7QzLSG0vHZkw5ozK/IS0DYfabBNC6Qk4QjxpvDFE 9U4GXBEpMZQODBL0WmPmWDfgqeXPg550WbxLJO1fAi9CYQZ3Kkk1QtOkVf/iAYNjqgGC bio/hlLQVkro+6M6oLgk93YV5MZrj50s3SwDA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=sChpyrB1Ca/fu3CjzpX6ksGYhJjg0fXLwKTI5ZiMweZg0Jje+74LT5Qf6pl/jtEFrJ G0c2yc7nhaEAuyf8DuyTAiTdpQk98DagoVpBD5/CKAwKaZHLWs6FLu+ugkIrR/kg0dhL Bpc90lnh1XOBBOB4ML4KFz3KScDexM4r4CyHE= MIME-Version: 1.0 Received: by 10.140.178.4 with HTTP; Sat, 3 Apr 2010 19:50:12 -0700 (PDT) In-Reply-To: <21301.1270314309@sss.pgh.pa.us> References: <21301.1270314309@sss.pgh.pa.us> Date: Sun, 4 Apr 2010 08:20:12 +0530 Received: by 10.140.55.12 with SMTP id d12mr2719649rva.208.1270349412975; Sat, 03 Apr 2010 19:50:12 -0700 (PDT) Message-ID: Subject: Re: ERROR: cache lookup failed for relation X From: raghavendra t To: Tom Lane Cc: pgsql-general@postgresql.org Content-Type: multipart/alternative; boundary=0050450294be80430704836045e1 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-2.598 tagged_above=-10 required=5 tests=BAYES_00=-2.599, HTML_MESSAGE=0.001 X-Spam-Level: X-Archive-Number: 201004/147 X-Sequence-Number: 161345 --0050450294be80430704836045e1 Content-Type: text/plain; charset=ISO-8859-1 Hi Tom, Thank you for your Prompt reply.. Am getting this error only in the application level that too with multiple sessions. By getting that error am assuming that the table has got dropped in some other session. I understood from here is that its not a serious problem to catalog Corruption. Regards Raghavendra On Sat, Apr 3, 2010 at 10:35 PM, Tom Lane wrote: > raghavendra t writes: > > I am facing the error "cache lookup failed for relation X" in > Postgres-8.4.2 > > [ when dropping the same table concurrently in two sessions ] > > Could plese tell me, why this is generated and what is the cause. > > From the perspective of session B, the table disappeared after it had > already found the table in the catalogs and obtained a lock on it. > This is not readily distinguishable from a serious problem such as > catalog corruption. While we could play dumb and just issue a > "table does not exist" message as though we'd never found it in the > catalog at all, that behavior could mask real problems, so it seems > better to not try to hide that something unusual happened. > > In general I would say that an application that is trying to do this > has got its own problems anyway --- how do you know which version of > the table you're dropping, and that that's the right thing? > > regards, tom lane > --0050450294be80430704836045e1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Tom,
=A0
Thank you for your Prompt reply..
=A0
Am getting this error only in the application level that too with mult= iple sessions. By getting that error am assuming that the table has got dro= pped in some other session.=A0
I understood from here is that its not a serious problem=A0to catalog = Corruption.
Regards
Raghavendra
On Sat, Apr 3, 2010 at 10:35 PM, Tom Lane <tgl@sss.pgh.pa.us&= gt; wrote:
raghavendra t <raagavendra.rao@gmail.com> writes:
> I am facing the err= or "cache lookup failed for relation X" in Postgres-8.4.2
> [ when dropping the same table concurrently in two sessions ]
> Could plese tell me, why this is generated and what = is the cause.

From the perspective of session B, the table dis= appeared after it had
already found the table in the catalogs and obtain= ed a lock on it.
This is not readily distinguishable from a serious problem such as
catal= og corruption. =A0While we could play dumb and just issue a
"table = does not exist" message as though we'd never found it in the
catalog at all, that behavior could mask real problems, so it seems
bett= er to not try to hide that something unusual happened.

In general I = would say that an application that is trying to do this
has got its own = problems anyway --- how do you know which version of
the table you're dropping, and that that's the right thing?

= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0regards, tom lane

--0050450294be80430704836045e1--