Making sure this isn't a new recovery bug ...
От | Josh Berkus |
---|---|
Тема | Making sure this isn't a new recovery bug ... |
Дата | |
Msg-id | 5589CA84.9080101@agliodbs.com обсуждение исходный текст |
Список | pgsql-hackers |
Hackers, At one site, I have some duplicate row corruption in a staging database.This database was created by a binary backup from9.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
В списке pgsql-hackers по дате отправления: