Re: BUG #8656: Duplicate data violating unique constraints

Interesting. And that was the pg_controldata of the live database. The
PITR, which is a few days older, has a much lower NextMultiXactId (and I'm
including everything else, since I'm not sure what's relevant and what
isn't):

pg_control version number:            937
Catalog version number:               201306121
Database system identifier:           5951409877055172578
Database cluster state:               in production
pg_control last modified:             Tue 10 Dec 2013 01:30:39 AM UTC
Latest checkpoint location:           14/6E000060
Prior checkpoint location:            14/6C000060
Latest checkpoint's REDO location:    14/6E000028
Latest checkpoint's REDO WAL file:    00000002000000140000006E
Latest checkpoint's TimeLineID:       2
Latest checkpoint's PrevTimeLineID:   2
Latest checkpoint's full_page_writes: on
Latest checkpoint's NextXID:          0/715897
Latest checkpoint's NextOID:          655360
Latest checkpoint's NextMultiXactId:  269003
Latest checkpoint's NextMultiOffset:  556707
Latest checkpoint's oldestXID:        1845
Latest checkpoint's oldestXID's DB:   1
Latest checkpoint's oldestActiveXID:  715897
Latest checkpoint's oldestMultiXid:   1
Latest checkpoint's oldestMulti's DB: 1
Time of latest checkpoint:            Tue 10 Dec 2013 01:30:38 AM UTC
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:            hot_standby
Current max_connections setting:      500
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:           1

We don't schedule vacuum specially: we just depend on autovacuum. Our
pg_restore wrapper was used to set up this database, so I know we ran
ANALYZE (on the whole DB) after the data load, but that's it. The user is
quite certain that he has never run VACUUM FREEZE on this instance (and we
did not do so either).

And no special settings exist for that table (in fact, reloptions is null
for every table in pg_class--or is there somewhere else I might need to
look?).

Could there be other edge cases having to do with a brand-new instance? I
think I mentioned that initdb was just a day or so before the error was
first noticed.