"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