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

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@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers