RE: CURRENT OF cursor without OIDs

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