ERROR: MultiXactId xxxx has not been created yet -- apparent wraparound - Mailing list pgsql-hackers

With PostgreSQL 9.3.5 on Ubuntu 12.04, I'm getting the error:

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

on doing various queries on our database. I don't think it is a 
wraparound - I think the tuple has mistakenly decided it has a 
MultiXactId related to it.

Looking back through the logs, it looks as if this suddenly started 
happening at 2:00 (UTC+0100) on 23 May. (Nothing was happening at that 
time as far as we can tell - the server didn't crash/restart or anything).

The logs were all really small, until the ones from then onwards, which 
are now full of things like:

2015-05-23 10:44:54 BST ERROR:  MultiXactId 1129406840 has not been 
created yet -- apparent wraparound
2015-05-23 10:44:54 BST CONTEXT:  automatic analyze of table 
"xxxxx.messages.msgdata"
2015-05-23 10:45:16 BST ERROR:  MultiXactId 1575170 has not been created 
yet -- apparent wraparound
2015-05-23 10:45:16 BST STATEMENT:  select sum(size) from messages.msgdata
2015-05-23 10:45:54 BST ERROR:  MultiXactId 1129406840 has not been 
created yet -- apparent wraparound
2015-05-23 10:45:54 BST CONTEXT:  automatic analyze of table 
"xxxxx.messages.msgdata"
2015-05-23 10:46:54 BST ERROR:  MultiXactId 1129406840 has not been 
created yet -- apparent wraparound

(There are several incorrect MultiXactIds in there).

This was NOT an upgrade. It has been running with 9.3 for ages.

The pg_controldata output is:

pg_control version number:            937
Catalog version number:               201306121
Database system identifier:           5990773948116871611
Database cluster state:               in production
pg_control last modified:             Tue 26 May 2015 09:50:25 BST
Latest checkpoint location:           7C6/8F863440
Prior checkpoint location:            7C6/8E8576D8
Latest checkpoint's REDO location:    7C6/8E8745F8
Latest checkpoint's REDO WAL file:    00000001000007C60000008E
Latest checkpoint's TimeLineID:       1
Latest checkpoint's PrevTimeLineID:   1
Latest checkpoint's full_page_writes: on
Latest checkpoint's NextXID:          0/24005839
Latest checkpoint's NextOID:          1802564
Latest checkpoint's NextMultiXactId:  216
Latest checkpoint's NextMultiOffset:  439
Latest checkpoint's oldestXID:        710
Latest checkpoint's oldestXID's DB:   1
Latest checkpoint's oldestActiveXID:  0
Latest checkpoint's oldestMultiXid:   1
Latest checkpoint's oldestMulti's DB: 1
Time of latest checkpoint:            Tue 26 May 2015 09:45:57 BST
Fake LSN counter for unlogged rels:   0/1
Minimum recovery ending location:     0/0
Min recovery ending loc's timeline:   0
Backup start location:                0/0
Backup end location:                  0/0
End-of-backup record required:        no
Current wal_level setting:            minimal
Current max_connections setting:      200
Current max_prepared_xacts setting:   0
Current max_locks_per_xact setting:   64
Maximum data alignment:               8
Database block size:                  8192
Blocks per segment of large relation: 131072
WAL block size:                       8192
Bytes per WAL segment:                16777216
Maximum length of identifiers:        64
Maximum columns in an index:          32
Maximum size of a TOAST chunk:        1996
Date/time type storage:               64-bit integers
Float4 argument passing:              by value
Float8 argument passing:              by value
Data page checksum version:           0

The pg_multixact directory contains two files
members/0000
offsets/0000

There are no locked up transactions is pg_stat_activity;

Any ideas? I can't even delete the records with the bad multixactid in 
them (which would be acceptable, as we can recover those individual 
records from backup). We don't want to restore fully from backup if 
possible as that will lose everything since the last good backup.