On Thu, 2008-11-20 at 11:51 +0530, Pavan Deolasee wrote:
> 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 like this idea. I've attempted to plug every gap, but perhaps the best
way here is to remove the gap completely.
In my testing, I only saw this case happen a couple of times in many
tests. Rarely executed code gives sporadic bugs, so I would be happy to
remove it and the standby support stuff that goes with it.
I would suggest that we just remove the switch statement:switch (HeapTupleSatisfiesVacuum(tuple.t_data, OldestXmin,
buf))
and alter the following if test since tupgone is also removed.
That will cause HEAPTUPLE_DEAD rows to be fed to heap_freeze_tuple().
Comments on that function claim that is a bad thing, but we know that
any row that was *not* removed by heap_page_prune() and is now dead must
have died very recently and so will never be frozen.
Let me know if you're happy with that change and I'll make it so.
-- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support