Re: CURRENT OF cursor without OIDs - Mailing list pgsql-hackers

From Hiroshi Inoue
Subject Re: CURRENT OF cursor without OIDs
Date
Msg-id 3B71D11C.4D79601F@tpf.co.jp
Whole thread Raw
In response to RE: CURRENT OF cursor without OIDs  ("Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: To be 7.1.3 or not to be 7.1.3?
Next
From: Hiroshi Inoue
Date:
Subject: Re: CURRENT OF cursor without OIDs