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
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