[Wood, Dan <hexpert@amazon.com>]

pg_check_frozen() reports corrupted VM freeze state.

Found with one of my stress tests.  Simplified to the repro below.

The reason for the 33 rows/pages is that I wanted to test if a 2nd vacuum freeze repaired the situation.  I was confounded till I discovered SKIP_PAGES_THRESHOLD was 32. 

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;
        }

BASH script repro below:

#!/bin/bash

p="psql -h 127.0.0.1 -p 5432 postgres"

echo "create extension pg_visibility;" | $p

$p <<XXX
drop table t;
create table t (i int primary key, c char(7777));
alter table t alter column c set storage plain;
insert into t select generate_series(0, 32, 1), 'XXX';
XXX

# Start two share lockers in the background
$p <<XXX >/dev/null &
begin;
select i, length(c) from t for share;
select pg_sleep(2);
commit;
XXX

$p <<XXX >/dev/null &
begin;
select i, length(c) from t for share;
select pg_sleep(2);
commit;
XXX

# Freeze while multixact locks are held
echo "vacuum freeze t;" | $p
echo "select pg_check_frozen('t');" | $p

sleep 4;  # Wait for share locks to be released

# See if another freeze corrects the problem
echo "vacuum freeze t;" | $p
echo "select pg_check_frozen('t');" | $p