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