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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
