Hiroshi wrote:
> > > > >    There could be DELETE operations for the tuple
> > > > >    from other backends also and the TID may disappear.
> > > > >    Because FULL VACUUM couldn't run while the cursor
> > > > >    is open, it could neither move nor remove the tuple
> > > > >    but I'm not sure if the new VACUUM could remove
> > > > >    the deleted tuple and other backends could re-use
> > > > >    the space under such a situation.
> > > >
> > > > If you also save the tuple transaction info (xmin ?) during the
> > > > select in addition to xtid, you could see whether the tupleslot
was
> > > > reused ?
> > >
> > > I think TID itself is available for the purpose as long as
> > > PostgreSQL uses no overwrite storage manager. If the tuple
> > > for a saved TID isn't found, the tuple may be update/deleted.
> > 
> > > If the tuple is found but the OID is different from the saved
> > > one, the space may be re-used.

space *was* reused (not "may be") 

> > 
> > But I meant in lack of an OID (per not mandatory oid), that xmin
> > might be a valid replacement for detecting, no ?
> 
> Does *current (ctid, xmin) == saved (ctid, xmin)* mean that
> they are same ?

Yes? but better ask Vadim ? Wraparound issue would be solved by
FrozenXID
and frequent vacuum.

> In addtion, xmin wouldn't be so reliable
> in the near future because it would be updated to FrozenXID
> (=2) by vacuum.

I thought concurrent vacuum with an open cursor is not at all possible. 
If it were, it would not be allowed to change ctid (location of row) 
and could be made to not change xmin. 

> If we switch to an overwriting smgr we have
> no item to detect the change of tuples. It may be one of the
> critical reasons why we shouldn't switch to an overwriting
> smgr:-).

If we still want MVCC, we would still need something like xmin
for overwrite smgr (to mark visibility).

Andreas

Thu, 23 Aug 2001 09:56:18 +0200
"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at>
RE: CURRENT OF cursor without OIDs
"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at> writes:
> Hiroshi wrote:
>> In addtion, xmin wouldn't be so reliable
>> in the near future because it would be updated to FrozenXID
>> (=2) by vacuum.

> I thought concurrent vacuum with an open cursor is not at all possible. 
> If it were, it would not be allowed to change ctid (location of row) 
> and could be made to not change xmin. 

New-style vacuum can certainly run concurrently with an open cursor
(wouldn't be of much use if it couldn't).  However, new-style vacuum
never changes ctid, period.  It could change the xmin of a tuple though,
under my not-yet-implemented proposal for freezing tuples.

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.  Old-style VACUUM might move the tuple and make the
ctid available for reuse, but your open cursor will prevent old-style
VACUUM from running on that table.  So, there's no need to look at xmin.

			regards, tom lane

Thu, 23 Aug 2001 11:01:13 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: CURRENT OF cursor without OIDs 
Tom Lane wrote:
> 
> "Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at> writes:
> > Hiroshi wrote:
> >> In addtion, xmin wouldn't be so reliable
> >> in the near future because it would be updated to FrozenXID
> >> (=2) by vacuum.
> 
> > I thought concurrent vacuum with an open cursor is not at all possible.
> > If it were, it would not be allowed to change ctid (location of row)
> > and could be made to not change xmin.
> 
> New-style vacuum can certainly run concurrently with an open cursor
> (wouldn't be of much use if it couldn't).  However, new-style vacuum
> never changes ctid, period.  It could change the xmin of a tuple though,
> under my not-yet-implemented proposal for freezing tuples.
> 
> 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.  Old-style VACUUM might move the tuple and make the
> ctid available for reuse, but your open cursor will prevent old-style
> VACUUM from running on that table.  So, there's no need to look at xmin.

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

regards,
Hiroshi Inoue

Fri, 24 Aug 2001 09:22:57 +0900
Hiroshi Inoue <Inoue@tpf.co.jp>
Re: CURRENT OF cursor without OIDs