> > 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

Thu, 23 Aug 2001 18:15:12 -0700
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM>
RE: CURRENT OF cursor without OIDs
"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

Fri, 24 Aug 2001 10:32:44 +0900
Hiroshi Inoue <Inoue@tpf.co.jp>
Re: CURRENT OF cursor without OIDs