RE: CURRENT OF cursor without OIDs
От | Zeugswetter Andreas SB SD |
---|---|
Тема | RE: CURRENT OF cursor without OIDs |
Дата | |
Msg-id | 46C15C39FEB2C44BA555E356FBCD6FA41EB375@m0114.s-mxs.net обсуждение исходный текст |
Ответ на | CURRENT OF cursor without OIDs (Ian Lance Taylor <ian@airs.com>) |
Ответы |
Re: CURRENT OF cursor without OIDs
|
Список | 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 по дате отправления: