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