Re: ERROR: MultiXactId xxxx has not been created yet -- apparent wraparound

From: Paul Smith <paul(at)pscs(dot)co(dot)uk>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: ERROR: MultiXactId xxxx has not been created yet -- apparent wraparound
Date: 2015-05-26 15:47:15
Message-ID: 55649583.1040206@pscs.co.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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).

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2015-05-26 15:58:00 Re: fsync-pgdata-on-recovery tries to write to more files than previously
Previous Message Andrew Dunstan 2015-05-26 15:43:32 Re: fsync-pgdata-on-recovery tries to write to more files than previously