"Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
> Hiroshi wrote:
>> In addtion, xmin wouldn't be so reliable
>> in the near future because it would be updated to FrozenXID
>> (=2) by vacuum.
> I thought concurrent vacuum with an open cursor is not at all possible.
> If it were, it would not be allowed to change ctid (location of row)
> and could be made to not change xmin.
New-style vacuum can certainly run concurrently with an open cursor
(wouldn't be of much use if it couldn't). However, new-style vacuum
never changes ctid, period. It could change the xmin of a tuple though,
under my not-yet-implemented proposal for freezing tuples.
AFAICS, if you are holding an open SQL cursor, it is sufficient to check
that ctid hasn't changed to know that you have the same, un-updated
tuple. Under MVCC rules, VACUUM will be unable to delete any tuple that
is visible to your open transaction, and so new-style VACUUM cannot
recycle the ctid. Old-style VACUUM might move the tuple and make the
ctid available for reuse, but your open cursor will prevent old-style
VACUUM from running on that table. So, there's no need to look at xmin.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
