Thread: Need help to debug ERROR: MultiXactId 808530957 has not been createdyet -- apparent
Hello,
Getting "MultiXactId 808530957 has not been created yet -- apparent" error when trying to VACUUM FREEZE big table, about 263m rows. Normal VACUUM runs fine.
1.Is it data corruption problem?
2.how to diagnose the error and possibly fix?
System:
CentOS 7.6.1810
PostgreSQL v10.7
pg_controldata output:
Latest checkpoint's full_page_writes: on
Latest checkpoint's NextXID: 0:225518418
Latest checkpoint's NextOID: 13806623
Latest checkpoint's NextMultiXactId: 3568437
Latest checkpoint's NextMultiOffset: 3991593
Latest checkpoint's oldestXID: 79505602
Latest checkpoint's oldestXID's DB: 16400
Latest checkpoint's oldestActiveXID: 225518416
Latest checkpoint's oldestMultiXid: 1666087
Latest checkpoint's oldestMulti's DB: 13806
Latest checkpoint's oldestCommitTsXid:0
Latest checkpoint's newestCommitTsXid:0
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
wal_level setting: replica
wal_log_hints setting: on
max_connections setting: 100
max_worker_processes setting: 8
max_prepared_xacts setting: 0
max_locks_per_xact setting: 64
track_commit_timestamp setting: off
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
Size of a large-object chunk: 2048
Date/time type storage: 64-bit integers
Float4 argument passing: by value
Float8 argument passing: by value
Data page checksum version: 0
Getting "MultiXactId 808530957 has not been created yet -- apparent" error when trying to VACUUM FREEZE big table, about 263m rows. Normal VACUUM runs fine.
Also tried to recreate the table and there were no errors "create table my_table_copy as
select * from my_table".
select * from my_table".
1.Is it data corruption problem?
2.how to diagnose the error and possibly fix?
System:
CentOS 7.6.1810
PostgreSQL v10.7
pg_controldata output:
Latest checkpoint's full_page_writes: on
Latest checkpoint's NextXID: 0:225518418
Latest checkpoint's NextOID: 13806623
Latest checkpoint's NextMultiXactId: 3568437
Latest checkpoint's NextMultiOffset: 3991593
Latest checkpoint's oldestXID: 79505602
Latest checkpoint's oldestXID's DB: 16400
Latest checkpoint's oldestActiveXID: 225518416
Latest checkpoint's oldestMultiXid: 1666087
Latest checkpoint's oldestMulti's DB: 13806
Latest checkpoint's oldestCommitTsXid:0
Latest checkpoint's newestCommitTsXid:0
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
wal_level setting: replica
wal_log_hints setting: on
max_connections setting: 100
max_worker_processes setting: 8
max_prepared_xacts setting: 0
max_locks_per_xact setting: 64
track_commit_timestamp setting: off
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
Size of a large-object chunk: 2048
Date/time type storage: 64-bit integers
Float4 argument passing: by value
Float8 argument passing: by value
Data page checksum version: 0
Re: Need help to debug ERROR: MultiXactId 808530957 has not beencreated yet -- apparent
From
Alvaro Herrera
Date:
On 2019-Jun-28, Jenn wrote: > Getting "MultiXactId 808530957 has not been created yet -- apparent" error > when trying to VACUUM FREEZE big table, about 263m rows. Normal VACUUM runs > fine. > Also tried to recreate the table and there were no errors "create table > my_table_copy as > select * from my_table". > > 1.Is it data corruption problem? > 2.how to diagnose the error and possibly fix? Yeah, it seems like data corruption -- that multixact value is not anywhere near a reasonable range. Can you find out what page it is complaining about, and get a heap_page_items() from that page? instructions for part 1: 1. in command line: gdb -p <pid>, where PID comes from "select pg_backend_pid()" in psql 2. in gdb, do "break errfinish", then "cont". It should wedge. 3. in psql, execute the query that throws the error 4. gdb becomes alive. Do "bt full". A page number is displayed somewhere in the resulting stack trace. If you don't know where to look, paste the output here. part 2: 1. create extension pageinspect 2. select * from heap_page_items(get_raw_page('yourtable'::regclass, <page number>)); 3. paste output here -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services