Re: Hot Standby (commit fest version - v5) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Hot Standby (commit fest version - v5)
Date
Msg-id 2197.1227195182@sss.pgh.pa.us
Whole thread Raw
In response to Re: Hot Standby (commit fest version - v5)  ("Pavan Deolasee" <pavan.deolasee@gmail.com>)
Responses Re: Hot Standby (commit fest version - v5)  (Simon Riggs <simon@2ndQuadrant.com>)
Re: Hot Standby (commit fest version - v5)  ("Pavan Deolasee" <pavan.deolasee@gmail.com>)
List pgsql-hackers
"Pavan Deolasee" <pavan.deolasee@gmail.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?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Updates of SE-PostgreSQL 8.4devel patches (r1197)
Next
From: Magnus Hagander
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Silence compiler warning about ignored return value.