Re: CURRENT OF cursor without OIDs
От | Hiroshi Inoue |
---|---|
Тема | Re: CURRENT OF cursor without OIDs |
Дата | |
Msg-id | 3B71EF92.32FBD5C@tpf.co.jp обсуждение исходный текст |
Ответ на | CURRENT OF cursor without OIDs (Ian Lance Taylor <ian@airs.com>) |
Ответы |
Re: CURRENT OF cursor without OIDs
|
Список | 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 по дате отправления: