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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Gurjeet Singh | 2011-01-06 21:28:19 | Re: Patch to add a primary key using an existing index |
Previous Message | Robert Haas | 2011-01-06 20:58:28 | Re: Problem with pg_upgrade (8.4 -> 9.0) due to ALTER DATABASE SET ROLE |