MultiXactId error after upgrade to 9.3.4 - Mailing list pgsql-hackers

Greetings,
 Looks like we might not be entirely out of the woods yet regarding MultiXactId's.  After doing an upgrade from 9.2.6
to9.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 /
CLUSTERfails, 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
indicativeof 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_MULTIand the xmax for all of the other tuples is quite a bit higher (though all are visible currently). 
 Thoughts?
   Thanks,
       Stephen