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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers