| From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-patches(at)postgresql(dot)org |
| Subject: | Re: Page at a time index scan |
| Date: | 2006-05-03 17:52:02 |
| Message-ID: | 1146678722.449.196.camel@localhost.localdomain |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-patches |
On Wed, 2006-05-03 at 13:39 -0400, Tom Lane wrote:
> Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> > So do you see a problem scenario like this?
>
> > A, B and C separate backends:
> > A1 Reads page, some row versions are *not* marked LP_DELETE but will be
> > later when A2 happens
> > B1 VACUUM removes dead rows, just happens to be all of them
> > B2 Recycles page into FSM
> > C1 Inserts new data into old page
> > A2 Attempts to update old page to notify about dead rows (UGH!)
>
> Can't happen; a page cannot be recycled until all concurrent
> transactions are gone. In any case, the LP_DELETE marking code will
> certainly take care to check that the entries it's trying to mark
> are still the same ones it meant to mark.
!
So do you see a problem with page deletion, or not? If so, what is it?
This patch looks good to me, based upon everything said.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2006-05-03 18:08:22 | Re: Page at a time index scan |
| Previous Message | Jim C. Nasby | 2006-05-03 17:47:55 | Re: patch review, please: Autovacuum/Vacuum times via stats. |