So freezing multixacts is not all that easy. I mean, you just scan the
page looking for multis lesser than the cutoff; for those that are dead,
they can just be removed completely, but what about ones that still have
members running? This is pretty unlikely but not impossible.
If there's only one remaining member, the problem is easy: replace it
with that transaction's xid, and set the appropriate hint bits. But if
there's more than one, the only way out is to create a new multi. This
increases multixactid consumption, but I don't see any other option.
However, there are cases where not even that is possible -- consider
tuple freezing during WAL recovery. Recovery is going to need to
replace those multis with other multis, but it cannot create new multis
itself. The only solution here appears to be that when multis are
frozen in the master, replacement multis have to be logged too. So the
heap_freeze_tuple Xlog record will have a map of old multi to new. That
way, recovery can just determine the new multi to use for any particular
old multi; since multixact creation is also logged, we're certain that
the replacement value has already been defined.
Sounds ugly, but not horrible.
Thoughts, opinions?
--
Álvaro Herrera <alvherre@alvh.no-ip.org>