Skip site navigation (1) Skip section navigation (2)

Re: BUG #6019: invalid cached plan on inherited table

From: Maxo EtDirloth <etdirloth(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #6019: invalid cached plan on inherited table
Date: 2011-05-11 06:21:59
Message-ID: BANLkTi=29JjraqCcgfKPpDf1qn7dkNryZA@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-bugs
No big deal to me, I just couldn't verify that it may occur only within
single transaction - not even in documentation.

thanks for the answer
.et.


On Wed, May 11, 2011 at 6:17 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> "" <etdirloth(at)gmail(dot)com> writes:
> > Cached execution plan of SQL stored procedure (which select from
> inherited
> > table) executed from within PLPGSQL function is used even when
> inheritance
> > descendant is already removed.
>
> Don't hold your breath waiting for a fix for that :-(.  There isn't any
> support for detecting plan-invalidation events for SQL-language
> functions, and in most situations it would be overkill because the plans
> are only cached for the lifespan of one calling query anyway.  The only
> case where the plan could survive longer is this specific example of a
> SQL function called from a "simple expression" in a plpgsql function,
> and even then it only survives for one complete transaction.
>
> I've thought for some time that SQL functions should be reimplemented
> to cache information more the way plpgsql functions do, ie, with a
> session-lifespan data structure for each function.  If we did that
> and made the individual query plans be stored in plancache, then
> invalidation of this type would occur automatically --- and, not
> insignificantly, the plans would survive long enough to pay back the
> added overhead of tracking invalidation causes for them.
>
> A somewhat related point is that people have occasionally complained
> because all the queries in a SQL function are run through parse analysis
> at once, causing things like
>
>                CREATE TABLE foo ... ;
>                INSERT INTO foo ... ;
>
> to not work because the second command is analyzed before the first is
> executed.  If we were reimplementing SQL functions then it'd make sense
> to try to do something about that at the same time.
>
> None of this is on the TODO list, but I'll go fix that momentarily.
>
>                        regards, tom lane
>

In response to

pgsql-bugs by date

Next:From: psql dp showing empty Access privileges column for {}Date: 2011-05-11 07:10:21
Subject: BUG #6021: There is no difference between default and empty access privileges with \dp
Previous:From: Craig RingerDate: 2011-05-11 06:17:51
Subject: Re: BUG #5994: Can't excute DBI->connect to oracle by client site

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group