"Mikheev, Vadim" wrote: > > > > 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...
Oops I'm referring to client side cursors in our ODBC driver. We have no cross-transaction cursors yet though I'd like to see a backend cross-transaction cursor also. > > > 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? No. I need an OID-like column which is independent from the physical position of tuples other than TID. > 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... How do we detect the change of tuples from clients ? TIDs are invariant under osmgr. xmin is about to be unreliable for the purpose. regards, Hiroshi Inoue ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
