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

Re: DISCARD ALL ; stored procedures

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: DISCARD ALL ; stored procedures
Date: 2011-01-06 21:21:36
Message-ID: AANLkTi=9nAWzHFUSxBc9DTAjCz+ZqeMfpWtgLNV1k80s@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Thu, Jan 6, 2011 at 3:20 PM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> Greetings,
>
>  Looking at discard all, I was a bit suprised that 'DISCARD PLANS;'
>  doesn't clear out cached stored procedures.  To be honest, that's one
>  of the main reasons I'd see to use it.  I thought there had been some
>  discussion in the archives related to invalidating stored procedure
>  plans due to catalog or other changes, I would have thought it'd be
>  possible to hook into that to do the same on a DISCARD PLANS;.
>
>  Thoughts?  Is there an issue doing that?  It certainly seems like it'd
>  be a lot better than what he current documentation requires:
>
>  When necessary, the cache can be flushed by starting a fresh database
>  session.
>
>  Maybe we could use 'DISCARD PLPLANS;' or something, if people feel
>  there needs to be a seperate way to clear those.

this is a problem. under what circumstances would you want to discard
them and why?  the main problem I see with cached plpgsql plans is
interactions with search_path -- but DISCARD might not be the best way
to attack that problem.  There might be other reasons though.

merlin

In response to

Responses

pgsql-hackers by date

Next:From: Gurjeet SinghDate: 2011-01-06 21:28:19
Subject: Re: Patch to add a primary key using an existing index
Previous:From: Robert HaasDate: 2011-01-06 20:58:28
Subject: Re: Problem with pg_upgrade (8.4 -> 9.0) due to ALTER DATABASE SET ROLE

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