RE: CURRENT OF cursor without OIDs - Mailing list pgsql-hackers

From Zeugswetter Andreas SB SD
Subject RE: CURRENT OF cursor without OIDs
Date
Msg-id 46C15C39FEB2C44BA555E356FBCD6FA41EB375@m0114.s-mxs.net
Whole thread Raw
In response to CURRENT OF cursor without OIDs  (Ian Lance Taylor <ian@airs.com>)
Responses Re: CURRENT OF cursor without OIDs
List pgsql-hackers
>    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.

Andreas


pgsql-hackers by date:

Previous
From: Doug McNaught
Date:
Subject: Re: Re: Client Side Connection Pooling
Next
From: Jan Wieck
Date:
Subject: Re: Question about todo item