| From: | Marko Tiikkaja <marko(at)joh(dot)to> | 
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> | 
| Subject: | Re: cache invalidation for PL/pgsql functions | 
| Date: | 2015-05-01 13:09:36 | 
| Message-ID: | 55437B10.7070107@joh.to | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
On 2015-04-28 19:43, Robert Haas wrote:
> I guess
> the root of the problem is that PL/plgsql's cache invalidation logic
> only considers the pg_proc row's TID and xmin when deciding whether to
> recompile.  For base types that's probably OK, but for composite
> types, not so much.
>
> Thoughts?
We recently hit a similar case in our production environment.  What was 
annoying about it is that there didn't seem to be a way for the 
application to fix the issue by itself, short of reconnecting; even 
DISCARD ALL doesn't help.  If we can't fix the underlying issue, can we 
at least provide a way for apps to invalidate these caches themselves, 
for example in the form of a DISCARD option?
.m
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Petr Jelinek | 2015-05-01 13:13:28 | Re: proposal: disallow operator "=>" and use it for named parameters | 
| Previous Message | Bruce Momjian | 2015-05-01 13:01:47 | Re: proposal: disallow operator "=>" and use it for named parameters |