Re: ERROR: MultiXactId xxxx has not been created yet -- apparent wraparound - Mailing list pgsql-hackers

From Paul Smith
Subject Re: ERROR: MultiXactId xxxx has not been created yet -- apparent wraparound
Date
Msg-id 55649583.1040206@pscs.co.uk
Whole thread Raw
In response to Re: ERROR: MultiXactId xxxx has not been created yet -- apparent wraparound  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: ERROR: MultiXactId xxxx has not been created yet -- apparent wraparound  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers

On 26/05/2015 16:01, Alvaro Herrera wrote:
> Paul Smith wrote:
>> With PostgreSQL 9.3.5 on Ubuntu 12.04, I'm getting the error:
>>
>> ERROR:  MultiXactId 1934308693 has not been created yet -- apparent
>> wraparound
>>
>> on doing various queries on our database. I don't think it is a wraparound -
>> I think the tuple has mistakenly decided it has a MultiXactId related to it.
> Yeah, that looks like the case.  According to your pg_controldata
> output, you haven't used many multixacts at all:
Yep, that's what I thought as well.

> so it doesn't seem plausible that the single bit HEAP_XMAX_IS_MULTI 
> was turned on accidentally (something which I've never seen happen). 
> It doesn't look like a randomly corrupt page either; normally you 
> would see errors about mismatching page headers before you get to the 
> point where Xmax is read. I wonder if the data page came from 
> elsewhere. Maybe you copied a data file from another database? 

No, nothing like that. It was just running fine, and then suddenly (at 
2am on 23 May) it started throwing up loads of these errors. The DB 
server wasn't even restarted at that point. It was just working fine, 
then suddenly wasn't. (The first error was at 02:00:32 BST, then every 
few minutes after that there's another one).

It's running in a Hyper-V guest. We had taken a backup of the VM at 
00:34 on 23 May and that looks to be absolutely fine. What I have done 
now is restore that backup and import the new data which arrived since 
that backup was made, and it seems OK now. I still have the 'broken' 
installation in case more information is needed from it. I'd try to get 
a raw dump of the damaged tuple data if I knew how to find where it is 
in the relation file...

I suppose it's possible that it was disk or memory corruption, but I've 
seen that before, and it hasn't looked like this. (There are several 
PostgreSQL guests running on the same Hyper-V server, and none of the 
others seem to have this problem which may suggest that it's less likely 
to be a hardware issue).





pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: fsync-pgdata-on-recovery tries to write to more files than previously
Next
From: Tom Lane
Date:
Subject: Re: fsync-pgdata-on-recovery tries to write to more files than previously