From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Hot Standby (commit fest version - v5) |
Date: | 2008-11-20 16:14:01 |
Message-ID: | 1227197641.7015.56.camel@ebony.2ndQuadrant |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, 2008-11-20 at 10:33 -0500, Tom Lane wrote:
> "Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com> writes:
> > I wonder if we should refactor lazy_scan_heap() so that *all* the real work
> > of collecting information about dead tuples happens only in
> > heap_page_prune(). Frankly, there is only a rare chance that a tuple may
> > become DEAD after the pruning happened on the page. We can ignore such
> > tuples; they will be vacuumed/pruned in the next cycle.
>
> > This would save us a second check of HeapTupleSatisfiesVacuum on the tuples
> > which are just now checked in heap_page_prune(). In addition, the following
> > additional WAL records are then not necessary because heap_page_prune() must
> > have already logged the latestRemovedXid.
>
> I don't think you can do that. Couldn't someone else have run
> heap_page_prune between vacuum's first and second visit to the page?
I just looked at that in more detail and decided it was more difficult
than it first appeared. So I've left it for now.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2008-11-20 16:55:51 | Re: WIP parallel restore patch |
Previous Message | Pavan Deolasee | 2008-11-20 16:13:23 | Re: Hot Standby (commit fest version - v5) |