Tom Lane wrote:
>
> Hiroshi Inoue <Inoue@tpf.co.jp> writes:
>
> > 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.
>
> Of course not. Concurrent VACUUM has to follow the same rules as
> old-style VACUUM: it must never remove or move any tuple that is still
> visible to any open transaction. (Actually, it never moves tuples at
> all, but the point is that it cannot remove any tuple that the open
> cursor could have seen.) So, the fact that SQL cursors don't survive
> across transactions is enough to guarantee that a TID returned by a
> cursor is good as long as the cursor is open.
>
> The reason you have a harder time with ODBC cursors is that you aren't
> restricting them to be good only within a transaction (or at least
> that's how I interpreted what you said earlier).
>
Yes mainly but I want the verification by OID even in
*inside a transaction* cases. For example,
1) A backend tx1 fetch a row using cursor.
2) Very old backend tx_old deletes the row and commits.
3) The new VACUUM starts to run and find the row to be completely dead.
The page is pinned by tx1, so the new VACUUM refuses
to change the page ? I there could be another story.
2)' Very old backend tx_old updated the row and deletes the updated row and commits.
3)' The new VACUUM starts to run and find the updated row to be completely dead but the page may not be pinned.
Both seems to be detected by FULL VACUUM as
'NOTICE: Child itemid in update-chain marked as unused - can't
continue repair_frag' though it may be too late.
regards,
Hiroshi Inoue