| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Florian G(dot) Pflug" <fgp(at)phlo(dot)org> |
| 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:11:15 |
| Message-ID: | 12943.1154347875@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
"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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2006-07-31 12:11:39 | Re: Questions about update, delete, ctid... |
| Previous Message | Florian G. Pflug | 2006-07-31 10:31:43 | Re: Questions about update, delete, ctid... |