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