Making sure this isn't a new recovery bug ... - Mailing list pgsql-hackers

From Josh Berkus
Subject Making sure this isn't a new recovery bug ...
Date
Msg-id 5589CA84.9080101@agliodbs.com
Whole thread Raw
List 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 by date:

Previous
From: Jim Nasby
Date:
Subject: Re: proposal: row_to_array function
Next
From: Kevin Grittner
Date:
Subject: Re: 9.5 release notes