Re: BUG #15060: Row in table not found when using pg function in an expression

Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> writes:
> "Marko" == Marko Tiikkaja <marko(at)joh(dot)to> writes:
> Marko> I'm not sure I understand. When's the snapshot used for planning
> Marko> actually taken here?

> GetCachedPlan will use either whatever snapshot is already set, if there
> is one, or it will set one of its own (actually at least two: separate
> snapshots for revalidate + parse analysis and for planning).

Hm. So we could improve on the fix I proposed earlier if there were a
way to tell GetCachedPlan "take a new snapshot even though there is an
active snapshot". It's still expensive, but at least the code path where
we use an existing generic plan doesn't get any added cost.

CC'ing Peter because of this part:

> The recent introduction of procedures exposes this interesting little
> variation in behavior (pg11 only):
> ...
> I assume that what's going on here is that the commit, which ends the
> transaction in which the DO was invoked and begins a new one, doesn't
> set a new active snapshot in the new transaction, and so planning of the
> perform in the second case is taking new snapshots inside GetCachedPlan.

I find this concerning. No part of plpgsql, or any other PL, has ever
before executed without the constant presence of an ActiveSnapshot.
It seems likely to me that this will expose, if not outright bugs,
at least strange differences in behavior between "procedure" code and
"function" code. Perhaps the commit-and-restart-transaction code ought
to include pushing a new ActiveSnapshot.

regards, tom lane