Re: cache lookup failed in plpgsql - reason? - Mailing list pgsql-hackers

From Robert Haas
Subject Re: cache lookup failed in plpgsql - reason?
Date
Msg-id CA+TgmobHVvO89F4OeGqbtge6tJN3u9xegpOSxOzDBC69Zd7jhg@mail.gmail.com
Whole thread Raw
In response to cache lookup failed in plpgsql - reason?  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers
On Wed, Oct 26, 2011 at 10:37 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
> Oct 25 20:13:44  db-s-01 postgres: <local5.warning> -- postgres[29970]:
> [3-1] 2011-10-25 20:13:44 CEST adifd 29970 ERROR:  cache lookup failed
> for relation 319883311
> Oct 25 20:13:44  db-s-01 postgres: <local5.warning> -- postgres[29970]:
> [3-2] 2011-10-25 20:13:44 CEST adifd 29970 CONTEXT:  SQL statement
> "SELECT  NOT EXISTS( SELECT relname FROM pg_class WHERE relname =

This appears to be a race condition in pg_table_is_visible.  It checks
whether the table exists; if it does not, it returns NULL.  Having
verified that the relation exists, it then calls RelationIsVisible(),
which then does a new syscache lookup for the same tuple, throwing an
error if none is found.  But there's no guarantee that things can't
change between the first test and the second one, so you get this
error.

Perhaps we could make RelationInVisible return a three-valued enum
type, rather than bool.   VISIBLE_YES, VISIBLE_NO, and
VISIBLE_NOTFOUND, or something like that.  I wouldn't want to
back-patch such a fix, since there could be third-party code calling
RelationIsVisible, but we could do it in master.  Sadly it's not a
trivial patch, since there are a gazillion WhateverIsVisible()
functions and we'd have to fix them all, but at least it's mostly
mechanical.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Alex Shulgin
Date:
Subject: Trivial libpq refactoring patch (was: Re: Another review of URI for libpq, v7 submission)
Next
From: Robert Haas
Date:
Subject: Re: [v9.2] Add GUC sepgsql.client_label