From: | "Florian G(dot) Pflug" <fgp(at)phlo(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | DANTE Alexandra <Alexandra(dot)Dante(at)bull(dot)net>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Questions about update, delete, ctid... |
Date: | 2006-07-31 12:40:55 |
Message-ID: | 44CDFA57.1070508@phlo.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Tom Lane wrote:
> "Florian G. Pflug" <fgp(at)phlo(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-07-31 12:46:28 | Re: Questions about update, delete, ctid... |
Previous Message | DANTE Alexandra | 2006-07-31 12:35:50 | Re: Questions about update, delete, ctid... |