> > 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 ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
