Re: Bug in prepared statement cache invalidation?

On Tue, May 2, 2017 at 6:07 AM, Konstantin Knizhnik
<k(dot)knizhnik(at)postgrespro(dot)ru> 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 so has to be recompiled if some of them are
> changed.
> It is not necessary to build closure of dependency graph - instead of it
> cascade invalidation can be used.
> So it is not clear to me where you see here the source of complexity and why
> this task may be "Turing-complete in some cases"?

Well, if the user's using PL/python or similar, they can do an
arbitrary computation and use the result as a table name. There's no
way for the core system to know what table name that will end up
referencing.

> The problem can be with overloaded functions and PL languages without static
> type checking.
> In this case resolving has to be performed at runtime during function
> evaluation. But there should be no such problem with PLpgSQL.

Yeah, maybe. But what if the PL/pgsql function calls some other
function that creates a table, and then tries to access that table
from the original function, or something like that? There are weird
cases, I think, where even in PL/pgSQL it's not easy to figure out for
sure what the dependencies are.

> 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.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company