Re: [HACKERS] Bug in prepared statement cache invalidation?
От | Robert Haas |
---|---|
Тема | Re: [HACKERS] Bug in prepared statement cache invalidation? |
Дата | |
Msg-id | CA+TgmoZt2VthEjJu=us045zowKs2HL_J=EyowBmU4pPwWTjSpg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Bug in prepared statement cache invalidation? (Konstantin Knizhnik <k.knizhnik@postgrespro.ru>) |
Ответы |
Re: [HACKERS] Bug in prepared statement cache invalidation?
|
Список | pgsql-hackers |
On Tue, May 2, 2017 at 3:10 PM, Konstantin Knizhnik <k.knizhnik@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
В списке pgsql-hackers по дате отправления: