Обсуждение: Cache lookup failed for relation message in PG 8.3.7
Any ideas why we would be receiving this cache lookup failed message?
PostgreSQL 8.3.7 64 bit, RHEL 5 64 bit OS
Linux hostname.net 2.6.18-92.el5 #1 SMP Tue Apr 29 13:16:15 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux
<2010-02-07 08:05:36 MST>ERROR: cache lookup failed for relation 391262678
<2010-02-07 08:05:36 MST>STATEMENT: SELECT n.nspname as "Schema",
c.relname as "Name",
CASE c.relkind WHEN 'r' THEN 'table' WHEN 'v' THEN 'view' WHEN 'i' THEN 'index' WHEN 'S' THEN 'sequence' WHEN 's' THEN 'special' END as "Type",
r.rolname as "Owner"
FROM pg_catalog.pg_class c
JOIN pg_catalog.pg_roles r ON r.oid = c.relowner
LEFT JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace
WHERE c.relkind IN ('r','')
AND n.nspname <> 'pg_catalog'
AND n.nspname !~ '^pg_toast'
AND pg_catalog.pg_table_is_visible(c.oid)
ORDER BY 1,2;
Thanks.
PostgreSQL 8.3.7 64 bit, RHEL 5 64 bit OS
Linux hostname.net 2.6.18-92.el5 #1 SMP Tue Apr 29 13:16:15 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux
<2010-02-07 08:05:36 MST>ERROR: cache lookup failed for relation 391262678
<2010-02-07 08:05:36 MST>STATEMENT: SELECT n.nspname as "Schema",
c.relname as "Name",
CASE c.relkind WHEN 'r' THEN 'table' WHEN 'v' THEN 'view' WHEN 'i' THEN 'index' WHEN 'S' THEN 'sequence' WHEN 's' THEN 'special' END as "Type",
r.rolname as "Owner"
FROM pg_catalog.pg_class c
JOIN pg_catalog.pg_roles r ON r.oid = c.relowner
LEFT JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace
WHERE c.relkind IN ('r','')
AND n.nspname <> 'pg_catalog'
AND n.nspname !~ '^pg_toast'
AND pg_catalog.pg_table_is_visible(c.oid)
ORDER BY 1,2;
Thanks.
Keaton Adams <Keaton_Adams@McAfee.com> writes: > Any ideas why we would be receiving this cache lookup failed message? > PostgreSQL 8.3.7 64 bit, RHEL 5 64 bit OS > [ query applying pg_table_is_visible() to most of pg_class ] Is it repeatable, or just something that shows up occasionally with different OIDs mentioned? If the latter, it's probably a known race condition against table drops: the pg_class scan can find rows that belong to tables that are already deleted by the time pg_table_is_visible gets called. There's a hack in 8.4 to avoid the errors by having pg_table_is_visible (and related functions) return null instead of failing, but I don't believe we changed it in previous releases. regards, tom lane