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-30 17:24:24 |
Message-ID: | 26281.1154280264@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:
> Martijn van Oosterhout wrote:
>> It's the t_ctid field of the tuple header. But I don't see what that
>> has to do with "WHERE CURRENT OF". That expression should return the
>> tuple visible to your transaction, not some updated version which you
>> won't be able to fetch. If you end up updating the old version, the
>> system will take care of finding the newer version if necessary.
> The problem is that the ctid of the tuple that "fetch" returned
> might not actually be the tuple that needs to be updated.
Martijn's got a point though: it's not clear that that needs any special
care on the part of WHERE CURRENT OF. It may be that the existing
EvalPlanQual machinery does everything that's needful. Is the example
you show really any different from updating a tuple that someone else
updated while your UPDATE was in progress? In both cases the EPQ
machinery will take care of chaining forward to the right version to
update.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | David Hoksza | 2006-07-30 17:54:32 | pg_statio_all_indexes |
Previous Message | Alvaro Herrera | 2006-07-30 16:48:33 | Re: Performance of the listen command |