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 по дате отправления:

Предыдущее
От: Jim Nasby
Дата:
Сообщение: Re: proposal: row_to_array function
Следующее
От: Kevin Grittner
Дата:
Сообщение: Re: 9.5 release notes