On 22.11.2010 21:24, Robert Haas wrote:
> Eh, so. Suppose - for the sake of argument - we do the following:
>
> 1. Allocate an additional infomask(2) bit that means "xmin is frozen,
> no need to call XidInMVCCSnapshot()". When we freeze a tuple, we set
> this bit in lieu of overwriting xmin. Note that freezing pages is
> already WAL-logged, so redo is possible.
>
> 2. Modify VACUUM so that, when the page is observed to be all-visible,
> it will freeze all tuples on the page, set PD_ALL_VISIBLE, and set the
> visibility map bit, writing a single XLOG record for the whole
> operation (possibly piggybacking on XLOG_HEAP2_CLEAN if the same
> vacuum already removed tuples; otherwise and/or when no tuples were
> removed writing XLOG_HEAP2_FREEZE or some new record type). This
> loses no forensic information because of (1). (If the page is NOT
> observed to be all-visible, we freeze individual tuples only when they
> hit the current age thresholds.)
>
> Setting the visibility map bit is now crash-safe.
That's an interesting idea. You pickyback setting the vm bit on the
freeze WAL record, on the assumption that you have to write the freeze
record anyway. However, if that assumption doesn't hold, because the
tuples are deleted before they reach vacuum_freeze_min_age, it's no
better than the naive approach of WAL-logging the vm bit set separately.
Whether that's acceptable or not, I don't know.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com