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

Поиск
Список
Период
Сортировка
От Paul Smith
Тема Re: ERROR: MultiXactId xxxx has not been created yet -- apparent wraparound
Дата
Msg-id 55649583.1040206@pscs.co.uk
обсуждение исходный текст
Ответ на Re: ERROR: MultiXactId xxxx has not been created yet -- apparent wraparound  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Ответы Re: ERROR: MultiXactId xxxx has not been created yet -- apparent wraparound  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: fsync-pgdata-on-recovery tries to write to more files than previously
Следующее
От: Tom Lane
Дата:
Сообщение: Re: fsync-pgdata-on-recovery tries to write to more files than previously