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

It was fixed in 9.3.7.

Unfortunately 9.3.7 has new bug which is irrelevant to this.
http://www.postgresql.org/message-id/20150525142657.4686.35151@wrigleys.postgresql.org

I'm not sure if Ubuntu 12.04 is affected by the bug or not though.

As far as I know developers plan to release 9.3.8 etc. soon.

Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp

> 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.
>
> Looking back through the logs, it looks as if this suddenly started
> happening at 2:00 (UTC+0100) on 23 May. (Nothing was happening at that
> time as far as we can tell - the server didn't crash/restart or
> anything).
>
> The logs were all really small, until the ones from then onwards,
> which are now full of things like:
>
> 2015-05-23 10:44:54 BST ERROR: MultiXactId 1129406840 has not been
> created yet -- apparent wraparound
> 2015-05-23 10:44:54 BST CONTEXT: automatic analyze of table
> "xxxxx.messages.msgdata"
> 2015-05-23 10:45:16 BST ERROR: MultiXactId 1575170 has not been
> created yet -- apparent wraparound
> 2015-05-23 10:45:16 BST STATEMENT: select sum(size) from
> messages.msgdata
> 2015-05-23 10:45:54 BST ERROR: MultiXactId 1129406840 has not been
> created yet -- apparent wraparound
> 2015-05-23 10:45:54 BST CONTEXT: automatic analyze of table
> "xxxxx.messages.msgdata"
> 2015-05-23 10:46:54 BST ERROR: MultiXactId 1129406840 has not been
> created yet -- apparent wraparound
>
> (There are several incorrect MultiXactIds in there).
>
> This was NOT an upgrade. It has been running with 9.3 for ages.
>
> The pg_controldata output is:
>
> pg_control version number: 937
> Catalog version number: 201306121
> Database system identifier: 5990773948116871611
> Database cluster state: in production
> pg_control last modified: Tue 26 May 2015 09:50:25 BST
> Latest checkpoint location: 7C6/8F863440
> Prior checkpoint location: 7C6/8E8576D8
> Latest checkpoint's REDO location: 7C6/8E8745F8
> Latest checkpoint's REDO WAL file: 00000001000007C60000008E
> Latest checkpoint's TimeLineID: 1
> Latest checkpoint's PrevTimeLineID: 1
> Latest checkpoint's full_page_writes: on
> Latest checkpoint's NextXID: 0/24005839
> Latest checkpoint's NextOID: 1802564
> Latest checkpoint's NextMultiXactId: 216
> Latest checkpoint's NextMultiOffset: 439
> Latest checkpoint's oldestXID: 710
> Latest checkpoint's oldestXID's DB: 1
> Latest checkpoint's oldestActiveXID: 0
> Latest checkpoint's oldestMultiXid: 1
> Latest checkpoint's oldestMulti's DB: 1
> Time of latest checkpoint: Tue 26 May 2015 09:45:57 BST
> Fake LSN counter for unlogged rels: 0/1
> Minimum recovery ending location: 0/0
> Min recovery ending loc's timeline: 0
> Backup start location: 0/0
> Backup end location: 0/0
> End-of-backup record required: no
> Current wal_level setting: minimal
> Current max_connections setting: 200
> Current max_prepared_xacts setting: 0
> Current max_locks_per_xact setting: 64
> Maximum data alignment: 8
> Database block size: 8192
> Blocks per segment of large relation: 131072
> WAL block size: 8192
> Bytes per WAL segment: 16777216
> Maximum length of identifiers: 64
> Maximum columns in an index: 32
> Maximum size of a TOAST chunk: 1996
> Date/time type storage: 64-bit integers
> Float4 argument passing: by value
> Float8 argument passing: by value
> Data page checksum version: 0
>
> The pg_multixact directory contains two files
> members/0000
> offsets/0000
>
> There are no locked up transactions is pg_stat_activity;
>
> Any ideas? I can't even delete the records with the bad multixactid in
> them (which would be acceptable, as we can recover those individual
> records from backup). We don't want to restore fully from backup if
> possible as that will lose everything since the last good backup.
>
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers