Re: Questions about update, delete, ctid...

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

In response to

Responses

Browse pgsql-general by date

  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...