Tom Lane wrote:
>
> "Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at> 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.
As Tom mentiond once in this thread, I've referred to non-SQL
cursors which could go across transaction boundaries. TIDs aren't
that reliable across transactions.
OIDs and xmin have already lost a part of its nature. Probably
I have to guard myself beforehand and so would have to mention
repeatedly from now on that if we switch to an overwriting smgr,
there's no system item to detect the change of tuples.
regards,
Hiroshi Inoue