| From: | Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Bug in prepared statement cache invalidation? |
| Date: | 2017-05-02 19:10:09 |
| Message-ID: | 5908D991.4010009@postgrespro.ru |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2017-05-02 19:13:58 | Re: modeling parallel contention (was: Parallel Append implementation) |
| Previous Message | Petr Jelinek | 2017-05-02 19:02:19 | Re: logical replication syntax (was DROP SUBSCRIPTION, query cancellations and slot handling) |