Em sexta-feira, 1 de maio de 2015, Robert Haas <robertmh...@gmail.com> escreveu:
> On Fri, May 1, 2015 at 9:09 AM, Marko Tiikkaja <ma...@joh.to > <javascript:;>> wrote: > > 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? > > It's been discussed before and I am in favor of it. However the > implementation is a bit challenging. The DISCARD command doesn't know > what PLs may have decided to cache, nonwithstanding the fact that they > all cache basically the same stuff using basically the same method. I > think the PL interface will need to be extended in some way to support > a new callback. > > IMHO we need a way to DISCARD run a cleanup code for each installed extension. Maybe with a new option like DISCARD EXTENSIONS. So each extension could have and register your own cleanup code. Regards, -- Fabrízio de Royes Mello Consultoria/Coaching PostgreSQL >> Timbira: http://www.timbira.com.br >> Blog: http://fabriziomello.github.io >> Linkedin: http://br.linkedin.com/in/fabriziomello >> Twitter: http://twitter.com/fabriziomello >> Github: http://github.com/fabriziomello
