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

From Hiroshi Inoue
Subject Re: CURRENT OF cursor without OIDs
Date
Msg-id 3B71EF92.32FBD5C@tpf.co.jp
Whole thread Raw
In response to CURRENT OF cursor without OIDs  (Ian Lance Taylor <ian@airs.com>)
Responses Re: CURRENT OF cursor without OIDs
List pgsql-hackers
Tom Lane wrote:
> 
> Hiroshi Inoue <Inoue@tpf.co.jp> writes:
> > 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.
> 
> This cannot happen.  If VACUUM thought that, VACUUM would be completely
> broken. Although the row is committed dead, it is still visible to the
> transaction using the cursor, so it must not be deleted.

Yes it should be but it could happen.
GetXmaxRecent() ignores the backend tx_old because it had been
committed when VACUUM started and may return the xid > the
very old xid of tx_old.  As far as I see, the current VACUUM
considers the row completely dead.

> This is true
> *whether or not the row has been fetched yet*, or ever will be fetched,
> by the cursor.
> 

I must apologize for leaving the bug unsolved.
Unfortunately VACUUM and MVCC are ill-suited.
For example, complicated update chain handling wasn't
needed before MVCC. 

regards,
Hiroshi Inoue


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: CURRENT OF cursor without OIDs
Next
From: Tom Lane
Date:
Subject: Re: CURRENT OF cursor without OIDs