From: | Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> |
---|---|
To: | Zeugswetter Andreas SB SD <ZeugswetterA(at)spardat(dot)at> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Ian Lance Taylor <ian(at)airs(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: CURRENT OF cursor without OIDs |
Date: | 2001-08-08 23:54:04 |
Message-ID: | 3B71D11C.4D79601F@tpf.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Hiroshi Inoue | 2001-08-09 00:20:55 | Re: CURRENT OF cursor without OIDs |
Previous Message | Tom Lane | 2001-08-08 23:35:42 | Re: To be 7.1.3 or not to be 7.1.3? |