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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
