Tom Lane wrote:
"Florian G. Pflug" <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
