cache lookup failed

Lists: pgsql-general
From: "Pascal Tufenkji" <ptufenkji(at)usj(dot)edu(dot)lb>
To: <pgsql-general(at)postgresql(dot)org>
Subject: cache lookup failed
Date: 2013-01-21 17:46:18
Message-ID: 00d601cdf7ff$3a3d7600$aeb86200$@usj.edu.lb
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-general

Hi,

I have an application that creates temp tables to speed up the fetching of
the data

Everything was working fine until a couple of days ago, the database is
starting to display the following error more and more

cache lookup failed for relation 1852615815

I noticed that this error keeps displaying when several users access the
system simultaneously

If I look up for this oid in pg_class I don’t find it, but I do find it in
pg_depend. Is that normal ?

dragon=# SELECT * from pg_class where oid = 1852615815;

relname | relnamespace | reltype | relowner | relam | relfilenode |
reltablespace | relpages | reltuples | reltoastrelid | reltoastidxid |
relhasindex | relisshared | relkind | relnatts | relchecks | reltriggers |
relukeys | relfkeys | relrefs | relhasoids | relhaspkey | relhasrules |
relhassubclass | relfrozenxid | relacl | reloptions

---------+--------------+---------+----------+-------+-------------+--------
-------+----------+-----------+---------------+---------------+-------------
+-------------+---------+----------+-----------+-------------+----------+---
-------+---------+------------+------------+-------------+----------------+-
-------------+--------+------------

(0 rows)

dragon=# SELECT * from pg_depend where objid = 1852615815;

classid | objid | objsubid | refclassid | refobjid | refobjsubid |
deptype

---------+------------+----------+------------+----------+-------------+----
-----

1259 | 1852615815 | 0 | 2615 | 111893 | 0 | n

(1 row)

dragon=# SELECT pg_table_is_visible(1852615815);

ERROR: cache lookup failed for relation 1852615815

Can anyone help please ?

What do I have to do to solve this issue ?

Thanks in advance

Pascal TUFENKJI
Service de Technologie de l'Information
Université Saint-Joseph - Rectorat
Tel: +961 1 421 132
Email: <mailto:ptufenkji(at)usj(dot)edu(dot)lb> ptufenkji(at)usj(dot)edu(dot)lb


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Pascal Tufenkji" <ptufenkji(at)usj(dot)edu(dot)lb>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: cache lookup failed
Date: 2013-01-22 03:52:58
Message-ID: 6942.1358826778@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-general

"Pascal Tufenkji" <ptufenkji(at)usj(dot)edu(dot)lb> writes:
> Everything was working fine until a couple of days ago, the database is
> starting to display the following error more and more
> cache lookup failed for relation 1852615815

Hm, what PG version is that? Is 1852615815 anywhere near the range of
existing OIDs in pg_class?

> If I look up for this oid in pg_class I dont find it, but I do find it in
> pg_depend. Is that normal ?

No --- at least not when the classid says it's a pg_class OID, as it
does here. Do you find any pg_depend rows with refobjid = 1852615815?
What about other rows mentioning OID 111893? Is that OID present in
pg_namespace? (The 2615 says it's a pg_namespace OID.)

We have seen some previous reports suggesting that once in awhile not
all the catalog entries associated with temp tables get cleaned out at
backend exit. I'm not sure the cause has ever been conclusively
identified, though if memory serves we have fixed a bug or two that
*might* explain it.

If 1852615815 doesn't seem to be a legitimate OID, it's also possible
that this is just data corruption in pg_depend.

If you can't find any evidence of other issues, it might be reasonable
to conclude that the pg_depend row is leftover junk and delete it
manually. But you should make real sure nothing is linked to it first.

regards, tom lane


From: "Pascal Tufenkji" <ptufenkji(at)usj(dot)edu(dot)lb>
To: "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <pgsql-general(at)postgresql(dot)org>
Subject: Re: cache lookup failed
Date: 2013-01-22 09:26:35
Message-ID: 004a01cdf882$941ae580$bc50b080$@usj.edu.lb
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-general

Dear Tom,

Thank you very much for your prompt reply...

I deleted this oid from pg_depend from both objid and refobjid
The problem disappeared
I also increased the following specs to avoid having this problem again:
- kernel.shmall
- kernel.shmmax

- shared_buffers
- max_fsm_pages
- max_fsm_relations
- effective_cache_size

Thanks again

Pascal TUFENKJI
Service de Technologie de l'Information
Université Saint-Joseph - Rectorat
Tel: +961 1 421 132
Email: ptufenkji(at)usj(dot)edu(dot)lb

-----Original Message-----
From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
Sent: Tuesday, January 22, 2013 5:53 AM
To: Pascal Tufenkji
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: [GENERAL] cache lookup failed

"Pascal Tufenkji" <ptufenkji(at)usj(dot)edu(dot)lb> writes:
> Everything was working fine until a couple of days ago, the database
> is starting to display the following error more and more cache lookup
> failed for relation 1852615815

Hm, what PG version is that? Is 1852615815 anywhere near the range of
existing OIDs in pg_class?

> If I look up for this oid in pg_class I don’t find it, but I do find
> it in pg_depend. Is that normal ?

No --- at least not when the classid says it's a pg_class OID, as it does
here. Do you find any pg_depend rows with refobjid = 1852615815?
What about other rows mentioning OID 111893? Is that OID present in
pg_namespace? (The 2615 says it's a pg_namespace OID.)

We have seen some previous reports suggesting that once in awhile not all
the catalog entries associated with temp tables get cleaned out at backend
exit. I'm not sure the cause has ever been conclusively identified, though
if memory serves we have fixed a bug or two that
*might* explain it.

If 1852615815 doesn't seem to be a legitimate OID, it's also possible that
this is just data corruption in pg_depend.

If you can't find any evidence of other issues, it might be reasonable to
conclude that the pg_depend row is leftover junk and delete it manually.
But you should make real sure nothing is linked to it first.

regards, tom lane