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 nobody's written yet.
>
> That mechanism already e
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 concerned:
register a s
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
>>> to be disappointing.
>>
>> T
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-lif
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
> relations/types/functions and s
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
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 here is that replanning and re
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 * fro
