"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at> writes:
> > There could be DELETE operations for the tuple
> > from other backends also and the TID may disappear.
> > Because FULL VACUUM couldn't run while the cursor
> > is open, it could neither move nor remove the tuple
> > but I'm not sure if the new VACUUM could remove
> > the deleted tuple and other backends could re-use
> > the space under such a situation.
>
> If you also save the tuple transaction info (xmin ?) during the
> select in addition to xtid, you could see whether the tupleslot was
> reused ?
> (This might need a function interface to make it reasonably portable to
> future
> versions)
> Of course the only thing you can do if you notice it has changed is bail
> out.
> But that leaves the question to me on what should actually be done when
> the tuple has changed underneath.
> I for one would not like the update to succeed if someone else modified
> it
> inbetween my fetch and my update.
If PL/pgSQL doesn't lock the table before doing the select, then I
think it has to mark the tuples for update when it does the select.
Unfortunately, the portal code explicitly rejects FOR UPDATE
(transformSelectStmt in parser/analyze.c).
Ian
