Making sure this isn't a new recovery bug ...

Hackers,

At one site, I have some duplicate row corruption in a staging database.
This database was created by a binary backup from 9.3.5, which was
restored via PITR with a timestamp target to 9.3.5, so known-bad
versions. The strange thing about the duplicate rows is that they were
all frozen prior to the original binary backup, as far as I can tell.
Here's a sample:

id | b_xmax | b_xmin | b_ctid
----------+--------+--------+--------------
48871010 | 0 | 2 | (1529664,1)
48871010 | 0 | 2 | (1529696,1)
48871024 | 0 | 2 | (1529697,1)
48871024 | 0 | 2 | (1529665,1)
48871033 | 0 | 2 | (1529666,1)
48871033 | 0 | 2 | (1529698,1)
48871041 | 0 | 2 | (1529697,2)
48871041 | 0 | 2 | (1529665,2)
48871043 | 0 | 2 | (1529698,2)
48871043 | 0 | 2 | (1529666,2)
48871049 | 0 | 2 | (1529667,1)
48871049 | 0 | 2 | (1529699,1)

This is about 1000 rows of a 100m row table.

So my question is, is this still likely to be one of the known multixact
issues? I'm asking because this whole system will get scrubbed and
replaced with 9.3.9 in a couple days, so if it's a bug we want to
investigate, I need to do forensics now.

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com