Re: cache invalidation for PL/pgsql functions

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: Raw Message | Whole Thread | 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

In response to

Responses

Browse pgsql-hackers by date

  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