On Tue, May 2, 2017 at 3:10 PM, Konstantin Knizhnik <k.knizh...@postgrespro.ru> wrote: > On 05/02/2017 09:30 PM, Robert Haas wrote: >>> I am not sure how critical is this problem. Definitely it rarely happens, >>> but lack of normal workarounds (restart backend, recreate function?) >>> seems >>> to be disappointing. >> >> The problem goes away if you reconnect. The problematic cache is only >> backend-lifetime. >> > Most of clients are not connected to the Postgres directly, them are using > some kind of connection pooling. > It means that backends are never restarted. And it will be necessary to > restart the whole service just because we do not have > dependency tracking mechanism for PL code. Even invalidation of all > functions in case of DDL seems to be more acceptable solution.
Yeah. I think there should be a way to tell a PL to flush any internal caches it is maintaining, some variant of DISCARD. But that would require a bunch of code that nobody's written yet. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
