> > 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.
...
>
> 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.
We could avoid reassignment of MyProc->xmin having cursors
opened across tx boundaries and so new-style vacuum wouldn't
remove old tuple versions...
> 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.
So, is tid ok to use for your purposes?
I think we'll be able to restore old tid along with other tuple
data from rollback segments, so I don't see any problem from
osmgr...
Vadim