Thread: ERROR: cache lookup failed for relation X
Hi All,
I am facing the error "cache lookup failed for relation X" in Postgres-8.4.2 version. As you all know, its a reproducable and below is the example.
This can be generated with two sessions;
Am opening two sessions here Session A and Session B
Session A
=========
step 1 - creating the table
=========
step 1 - creating the table
postgres=# create table cache(id integer);
step 2 - Create the trigger and the function on particular table
postgres=# CREATE FUNCTION cachefunc() RETURNS trigger AS $$
BEGIN
RETURN NEW;
END; $$ LANGUAGE plpgsql;
BEGIN
RETURN NEW;
END; $$ LANGUAGE plpgsql;
postgres=# CREATE TRIGGER cachetrig BEFORE INSERT ON cache FOR EACH ROW EXECUTE PROCEDURE cachefunc();
Step 3 - Inserting a row in a table
postgres=# insert into cache values (1);
Step 4 - Droping the table in BEGIN block and issuing the same drop in another session B
postgres=# begin;
postgres=# drop table cache;
postgres=# drop table cache;
step 5 - Open the second session B and issue the same command
postgres=# drop table cache; --- In session B, this will wait untill commit is issued by the Session A.
step 6 - Issue the commit in Session A
postgres=# commit;
Step -7 now we can the see the error in the session B
ERROR: cache lookup failed for relation X
Could plese tell me, why this is generated and what is the cause.
Thanks in advance
Regards
Raghavendra
Because You dropped/deleted the table cache in Session A.
The simplest way to look at it is Session B was lock out when the Drop table command was issued from Session A. Now when session B finally got its chance to drop/delete the table it was already gone .
What kind error were you expecting from Postgresql to Return when it can't find the table???
In the future please don't cross post to multiple lists.
---- Message from raghavendra t <raagavendra.rao@gmail.com> at 04-03-2010 10:08:11 PM ------
All legitimate Magwerks Corporation quotations are sent in a .PDF file attachment with a unique ID number generated by our proprietary quotation system. Quotations received via any other form of communication will not be honored.
CONFIDENTIALITY NOTICE: This e-mail, including attachments, may contain legally privileged, confidential or other information proprietary to Magwerks Corporation and is intended solely for the use of the individual to whom it addresses. If the reader of this e-mail is not the intended recipient or authorized agent, the reader is hereby notified that any unauthorized viewing, dissemination, distribution or copying of this e-mail is strictly prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and destroy all occurrences of this e-mail immediately.
Thank you.
The simplest way to look at it is Session B was lock out when the Drop table command was issued from Session A. Now when session B finally got its chance to drop/delete the table it was already gone .
What kind error were you expecting from Postgresql to Return when it can't find the table???
In the future please don't cross post to multiple lists.
---- Message from raghavendra t <raagavendra.rao@gmail.com> at 04-03-2010 10:08:11 PM ------
step 6 - Issue the commit in Session Apostgres=# commit;Step -7 now we can the see the error in the session BERROR: cache lookup failed for relation X
Could plese tell me, why this is generated and what is the cause.Thanks in advanceRegardsRaghavendra
All legitimate Magwerks Corporation quotations are sent in a .PDF file attachment with a unique ID number generated by our proprietary quotation system. Quotations received via any other form of communication will not be honored.
CONFIDENTIALITY NOTICE: This e-mail, including attachments, may contain legally privileged, confidential or other information proprietary to Magwerks Corporation and is intended solely for the use of the individual to whom it addresses. If the reader of this e-mail is not the intended recipient or authorized agent, the reader is hereby notified that any unauthorized viewing, dissemination, distribution or copying of this e-mail is strictly prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and destroy all occurrences of this e-mail immediately.
Thank you.
raghavendra t <raagavendra.rao@gmail.com> 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
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 <tgl@sss.pgh.pa.us> wrote:
raghavendra t <raagavendra.rao@gmail.com> writes:> [ when dropping the same table concurrently in two sessions ]
> I am facing the error "cache lookup failed for relation X" in Postgres-8.4.2> 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
Hi Justin,
Thank you for your reply..
In the future please don't cross post to multiple lists.
Appoligies for it...
Regards
Raghavendra
On Sat, Apr 3, 2010 at 10:34 PM, justin@magwerks.com <justin@magwerks.com> wrote:
Because You dropped/deleted the table cache in Session A.The simplest way to look at it is Session B was lock out when the Drop table command was issued from Session A. Now when session B finally got its chance to drop/delete the table it was already gone .What kind error were you expecting from Postgresql to Return when it can't find the table???In the future please don't cross post to multiple lists.---- Message from raghavendra t <raagavendra.rao@gmail.com> at 04-03-2010 10:08:11 PM ------step 6 - Issue the commit in Session Apostgres=# commit;Step -7 now we can the see the error in the session BERROR: cache lookup failed for relation XCould plese tell me, why this is generated and what is the cause.Thanks in advanceRegardsRaghavendraAll legitimate Magwerks Corporation quotations are sent in a .PDF file attachment with a unique ID number generated by our proprietary quotation system. Quotations received via any other form of communication will not be honored.CONFIDENTIALITY NOTICE: This e-mail, including attachments, may contain legally privileged, confidential or other information proprietary to Magwerks Corporation and is intended solely for the use of the individual to whom it addresses. If the reader of this e-mail is not the intended recipient or authorized agent, the reader is hereby notified that any unauthorized viewing, dissemination, distribution or copying of this e-mail is strictly prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and destroy all occurrences of this e-mail immediately.Thank you.