Re: pg_class_aclcheck: relation [oid] not found...

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Sean Chittenden <sean(at)chittenden(dot)org>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: pg_class_aclcheck: relation [oid] not found...
Date: 2003-05-28 19:08:23
Message-ID: 5737.1054148903@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Sean Chittenden <sean(at)chittenden(dot)org> writes:
> Hrm... this limitation makes temporary tables that drop on commit +
> pl/pgsql unusable beyond the 1st transaction. Is there a mechanism to
> test to see if a relation in a plan is a temporary table? It seems as
> though in pl_exec.c that around 1926 it'd be possible to add a test to
> see if the plan uses temporary tables and add a new member to struct
> expr telling exec_stmt_execsql to free the plan around line 2016 when
> its cleaning up after itself.

That's entirely the wrong way to go about it. Temp tables are only one
manifestation of a general problem with stale plans. For instance, if
someone drops an index that your query uses, you've got a problem.

What we need is a general mechanism that keeps track of all the DB
objects that a cached plan depends on (tables, views, functions, yadda
yadda) and invalidates the plan when any of those objects are dropped or
altered. At the low level, such a mechanism already exists (the
syscache inval stuff) --- the problem is to connect it up to plan
caching.

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Sean Chittenden 2003-05-29 00:14:00 segv's on CREATE INDEX with recent HEAD...
Previous Message Sean Chittenden 2003-05-28 18:30:37 Re: pg_class_aclcheck: relation [oid] not found...