MultiXactId error after upgrade to 9.3.4

Greetings,

Looks like we might not be entirely out of the woods yet regarding
MultiXactId's. After doing an upgrade from 9.2.6 to 9.3.4, we saw the
following:

ERROR: MultiXactId 6849409 has not been created yet -- apparent wraparound

The table contents can be select'd out and match the pre-upgrade
backup, but any attempt to VACUUM / VACUUM FULL / CLUSTER fails,
unsurprisingly.

I've just started looking into this, but here's a bit more data-

The *NEW* (9.3.4) cluster's pg_multixact files:

pg_multixact/members/

-rw------- 1 postgres postgres 8192 Mar 30 02:33 0000

pg_multixact/offsets/

-rw------- 1 postgres postgres 8192 Mar 28 01:11 0000
-rw------- 1 postgres postgres 122880 Mar 30 02:33 0018

The *OLD* (9.2.6) cluster's pg_multixact files:

pg_multixact/members/

-rw-rw-r-- 1 postgres postgres 188416 Mar 30 03:07 0044

pg_multixact/offsets/

-rw-rw-r-- 1 postgres postgres 114688 Mar 30 03:07 0018

txid_current - 40297693
datfrozenxid - 654

autovacuum_freeze_max_age, vacuum_freeze_min_age,
vacuum_freeze_table_age, multixact GUCs are commented out / default
values.

The *NEW* (9.3.4) control data shows:

pg_control version number: 937
Catalog version number: 201306121

Latest checkpoint's NextXID: 0/40297704
Latest checkpoint's NextOID: 53773598

Latest checkpoint's NextMultiXactId: 1601771
Latest checkpoint's NextMultiOffset: 1105

Latest checkpoint's oldestXID: 654
Latest checkpoint's oldestXID's DB: 12036
Latest checkpoint's oldestActiveXID: 40297704
Latest checkpoint's oldestMultiXid: 1601462
Latest checkpoint's oldestMulti's DB: 0

The *OLD* (9.2.6) control data had:

pg_control version number: 922
Catalog version number: 201204301

Latest checkpoint's NextXID: 0/40195831
Latest checkpoint's NextOID: 53757891

Latest checkpoint's NextMultiXactId: 1601462
Latest checkpoint's NextMultiOffset: 4503112

Latest checkpoint's oldestXID: 654
Latest checkpoint's oldestXID's DB: 12870
Latest checkpoint's oldestActiveXID: 0

(It doesn't report the oldestMulti info under 9.2.6).

The pg_upgrade reported:

Setting oldest multixact ID on new cluster

While testing, I discovered that this didn't appear to happen with a
(earlier) upgrade to 9.3.2. Don't know if it's indicative of
anything.

Here is what pageinspace shows for the record:

-[ RECORD 1 ]--------
lp | 45
lp_off | 5896
lp_flags | 1
lp_len | 50
t_xmin | 9663920
t_xmax | 6849409
t_field3 | 26930
t_ctid | (0,45)
t_infomask2 | 5
t_infomask | 6528
t_hoff | 24
t_bits |
t_oid |

Which shows xmax as 6849409 and HEAP_XMAX_IS_MULTI is set. This is
the only tuple in the table which has HEAP_XMAX_IS_MULTI and the xmax
for all of the other tuples is quite a bit higher (though all are
visible currently).

Thoughts?

Thanks,

Stephen