Re: BUG #15060: Row in table not found when using pg function in an expression
От | Tom Lane |
---|---|
Тема | Re: BUG #15060: Row in table not found when using pg function in an expression |
Дата | |
Msg-id | 29608.1518533639@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #15060: Row in table not found when using pg function in an expression (Andrew Gierth <andrew@tao11.riddles.org.uk>) |
Ответы |
Re: BUG #15060: Row in table not found when using pg function in an expression
|
Список | pgsql-bugs |
Andrew Gierth <andrew@tao11.riddles.org.uk> writes: > "Marko" == Marko Tiikkaja <marko@joh.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
В списке pgsql-bugs по дате отправления: