Re: cache invalidation for PL/pgsql functions - Mailing list pgsql-hackers

From Marko Tiikkaja
Subject Re: cache invalidation for PL/pgsql functions
Date
Msg-id 55437B10.7070107@joh.to
Whole thread Raw
In response to cache invalidation for PL/pgsql functions  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: cache invalidation for PL/pgsql functions  (Robert Haas <robertmhaas@gmail.com>)
List 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



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: proposal: disallow operator "=>" and use it for named parameters
Next
From: Petr Jelinek
Date:
Subject: Re: proposal: disallow operator "=>" and use it for named parameters