Re: VM map freeze corruption

My analysis is that heap_prepare_freeze_tuple->FreezeMultiXactId() returns FRM_NOOP if the MultiXACT locked rows haven't committed.  This results in changed=false and totally_frozen=true(as initialized).  When this returns to lazy_scan_heap(), no rows are added to the frozen[] array.  Yet, tuple_totally_frozen is true.  This means the page is marked frozen in the VM, even though the MultiXACT row wasn't left untouch.

A fix to heap_prepare_freeze_tuple() that seems to do the trick is:
        else
        {
            Assert(flags & FRM_NOOP);
+          totally_frozen = false;
        }