From: | Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Ian Lance Taylor <ian(at)airs(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: CURRENT OF cursor without OIDs |
Date: | 2001-08-09 02:04:02 |
Message-ID: | 3B71EF92.32FBD5C@tpf.co.jp |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
>
> Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2001-08-09 02:09:00 | Re: CURRENT OF cursor without OIDs |
Previous Message | Tom Lane | 2001-08-09 01:22:56 | Re: CURRENT OF cursor without OIDs |