Re: CURRENT OF cursor without OIDs
Inoue, Hiroshi <inoue@tpf.co.jp>
From: Hiroshi Inoue <Inoue@tpf.co.jp>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Ian Lance Taylor <ian@airs.com>, pgsql-hackers@postgresql.org
Date: 2001-08-09T02:04:02Z
Lists: 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