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  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: CURRENT OF cursor without OIDs
Следующее
От: Tom Lane
Дата:
Сообщение: Re: CURRENT OF cursor without OIDs