Re: [HACKERS] Bug in prepared statement cache invalidation?

2017-05-02 Thread Robert Haas
On Tue, May 2, 2017 at 5:50 PM, Tom Lane wrote: > Robert Haas writes: >> 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

Re: [HACKERS] Bug in prepared statement cache invalidation?

2017-05-02 Thread Tom Lane
Robert Haas writes: > 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. That mechanism already exists, so far as the core code is

Re: [HACKERS] Bug in prepared statement cache invalidation?

2017-05-02 Thread Robert Haas
On Tue, May 2, 2017 at 3:10 PM, Konstantin Knizhnik 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 >>>

Re: [HACKERS] Bug in prepared statement cache invalidation?

2017-05-02 Thread Konstantin Knizhnik
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

Re: [HACKERS] Bug in prepared statement cache invalidation?

2017-05-02 Thread Robert Haas
On Tue, May 2, 2017 at 6:07 AM, Konstantin Knizhnik wrote: > Thank you for explanation. > May be I am missing something, but what is the problem with keeping > dependencies for PL functions? > As you wrote, PL can inform core that functions depends on some set of >

Re: [HACKERS] Bug in prepared statement cache invalidation?

2017-05-02 Thread Konstantin Knizhnik
On 01.05.2017 16:09, Robert Haas wrote: This problem has been discussed before but nobody's done anything about it. The problem is a bit tricky because the core system doesn't know anything about the function caches maintained by individual PLs. I suppose ideally there'd be a way for a PL to

Re: [HACKERS] Bug in prepared statement cache invalidation?

2017-05-01 Thread Robert Haas
On Fri, Apr 28, 2017 at 3:01 AM, Konstantin Knizhnik wrote: > I find out that now Postgres correctly invalidates prepared plans which > directly depend on altered relation, but doesn't invalidate plans having > transitive (indirect) dependencies. I think the problem

[HACKERS] Bug in prepared statement cache invalidation?

2017-04-28 Thread Konstantin Knizhnik
Hi hackers, I find out that now Postgres correctly invalidates prepared plans which directly depend on altered relation, but doesn't invalidate plans having transitive (indirect) dependencies. Is it a bug or feature? postgres=# create table foo(x integer); CREATE TABLE postgres=# select *