Re: CURRENT OF cursor without OIDs

Zeugswetter Andreas SB SD 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. If we switch to an overwriting
storage manager, TID would be no longer transient and we need
another item like xmin to detect the change of rows.
I agree with you that detecting the change of rows is very
critical and xmin may be needed in the future.

regards,
Hiroshi Inoue