Обсуждение: 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
От
Alvaro Herrera
Дата:
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