Hiroshi Inoue <Inoue@tpf.co.jp> writes:
> 2) If no, there could be UPDATE operations for the
> current tuple from other backends between a
> SELECT and an UPDATE and the TID may be changed.
> In that case, you couldn't find the tuple using
> saved TID but you could use the functions to
> follow the UPDATE link which I provided when I
> I introduced Tis Scan.
Yes, you could either declare an error (if serializable mode) or follow
the TID links to find the latest version of the tuple, and update that
(if read-committed mode). This is no different from the situation for
any other UPDATE, AFAICS.
> 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.
Of course not. Concurrent VACUUM has to follow the same rules as
old-style VACUUM: it must never remove or move any tuple that is still
visible to any open transaction. (Actually, it never moves tuples at
all, but the point is that it cannot remove any tuple that the open
cursor could have seen.) So, the fact that SQL cursors don't survive
across transactions is enough to guarantee that a TID returned by a
cursor is good as long as the cursor is open.
The reason you have a harder time with ODBC cursors is that you aren't
restricting them to be good only within a transaction (or at least
that's how I interpreted what you said earlier).
regards, tom lane
