Re: HOT documentation README

On 9/12/07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
>
>
> VACUUM
> ------
>
> There is little change to regular vacuum. It removes dead HOT tuples,
> like pruning does, and cleans up any redirected dead line pointers.
>
> In lazy vacuum, we must not freeze a tuple that is in the middle of an
> update chain. That can happen when a tuple has xmin > xmax; it is the
> same scenario that requires "hard pruning" in VACUUM FULL. Freezing such
> tuples will break the check that xmin and xmax matches when following
> the chain. It is not a problem without HOT, because the preceding tuple
> in the chain must be dead as well so no one will try to follow the
> chain, but with HOT the preceding tuple would be DEAD_CHAIN, and someone
> might still need to follow the chain to find the live tuple. We avoid
> that by just not freezing such tuples. They can be frozen eventually,
> when the xmax of the preceding tuple is < OldestXmin as well.
>
> XXX doesn't the above completely break the anti-wraparound guarantees?
> And why couldn't we avoid the problem by pruning the previous tuple,
> which is surely dead?
>
>

We preserve anti-wraparound guarantees by not letting the relfrozenxid
advance past the minimum of cut-off xid and xmin/xmax of not-yet-frozen
tuples. Given that this is required to address corner case of DEAD tuple
following a RD tuple, the final relfrozenxid would be very close to the
cut-off xid. Isn't it ?

We could have actually pruned the preceding RD tuples (as we do in
vacuum full), but we were worried about missing some corner case
where someone may still want to follow the chain from the RD tuple.
We don't have any such concern with vacuum full because we run
with exclusive lock on the table. But if we agree that there is no
problem with pruning RD tuple preceding a DEAD tuple, we can
actually prune that tuple as well.

Thanks,
Pavan

--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com