Tom Lane wrote:
> "Florian G. Pflug" <fgp@phlo.org> writes:
>> I can see how the EPQ machinery can be used to chain forward to the
>> correct row to be updated, even if I originally found an older version
>> (e.g. by searching for a specific ctid). But for non-"for
>> update"-cursors, the newest version of the row returned by fetch could
>> be modified such that it would have never been returned by fetch in the
>> first place.
>
> Yah, EPQ checks for that ... none of the situations you've mentioned are
> any different from the case of an ordinary UPDATE that finds a row
> that's been modified since its snapshot was taken. A cursor would just
> make the time window a bit larger.
I don't get it. EPQ would need to reevaluate the plan of the _select_
belonging to the _cursor_, not the plan of the _update_, to prevent
the effect outlined above. Are you suggesting to use EPQ for that?
greetings, Florian Pflug
