Re: ERROR: found multixact from before relminmxid

From: Alexandre Arruda <adaldeia(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Peter Geoghegan <pg(at)bowt(dot)ie>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: ERROR: found multixact from before relminmxid
Date: 2018-04-11 02:54:04
Message-ID: CAGewt-trGM_xh-OZCf+xUs-x25ZFjCFkTXPLUCAGysH-Yq-DTw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

2018-04-10 19:53 GMT-03:00 Andres Freund <andres(at)anarazel(dot)de>:
> On 2018-04-10 08:31:20 -0300, Alexandre Arruda wrote:
>> 2018-04-09 23:51 GMT-03:00 Peter Geoghegan <pg(at)bowt(dot)ie>:
>> > On Mon, Apr 9, 2018 at 6:56 PM, Alexandre Arruda <adaldeia(at)gmail(dot)com> wrote:
>> >> (... and all other indexes returns null too)
>> >>
>> >> I tried with bt_index_check too. Same results.
>> >
>> > That's interesting, because it tells me that you have a table that
>> > appears to not be corrupt, despite the CLUSTER error. Also, the error
>> > itself comes from sanity checking added to MultiXact freezing fairly
>> > recently, in commit 699bf7d0.
>> >
>> > You didn't say anything about regular VACUUM being broken. Do you find
>> > that it works without any apparent issue?
>> >
>> > I have a suspicion that this could be a subtle bug in
>> > CLUSTER/freezing. The only heap_freeze_tuple() caller is code used by
>> > CLUSTER, so it's not that hard to imagine a MultiXact freezing bug
>> > that is peculiar to CLUSTER. Though I haven't thought about it in much
>> > detail.
>> >
>> > --
>> > Peter Geoghegan
>>
>> Hi Peter,
>>
>> Actualy, I first notice the problem in logs by autovacuum:
>>
>> 2018-04-10 08:22:15.385 -03 [55477] CONTEXT: automatic vacuum of
>> table "production.public.fn06t"
>> 2018-04-10 08:22:16.815 -03 [55477] ERROR: found multixact 68834765
>> from before relminmxid 73262006
>>
>> production=# vacuum analyze verbose fn06t;
>> INFO: vacuuming "public.fn06t"
>> ERROR: found multixact 76440919 from before relminmxid 122128619
>
> What does the function in
> https://www.postgresql.org/message-id/20180319181723.ugaf7hfkluqyos5d@alap3.anarazel.de
> say about your table?
>
> Could you post pg_controldata output and
> SELECT * FROM pg_class WHERE oid = 'public.fn06t'::regclass;
> ?
>
> Greetings,
>
> Andres Freund

pg_control version number: 1002
Catalog version number: 201707211
Database system identifier: 6513284223567708119
Database cluster state: in production
pg_control last modified: Ter 10 Abr 2018 23:51:56 BRT
Latest checkpoint location: 183/E4849618
Prior checkpoint location: 183/E19F8A80
Latest checkpoint's REDO location: 183/E202C430
Latest checkpoint's REDO WAL file: 0000000100000183000000E2
Latest checkpoint's TimeLineID: 1
Latest checkpoint's PrevTimeLineID: 1
Latest checkpoint's full_page_writes: on
Latest checkpoint's NextXID: 0:494263452
Latest checkpoint's NextOID: 1816390854
Latest checkpoint's NextMultiXactId: 256298856
Latest checkpoint's NextMultiOffset: 529468697
Latest checkpoint's oldestXID: 103399998
Latest checkpoint's oldestXID's DB: 866864162
Latest checkpoint's oldestActiveXID: 494263450
Latest checkpoint's oldestMultiXid: 73262006
Latest checkpoint's oldestMulti's DB: 866864162
Latest checkpoint's oldestCommitTsXid:0
Latest checkpoint's newestCommitTsXid:0
Time of latest checkpoint: Ter 10 Abr 2018 23:50:14 BRT
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: off
max_connections setting: 600
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
Mock authentication nonce:
a8eb07ea85c4bbeaf202020d036277b276bda47ef55c1456723ec2b3c40386b1

SELECT * FROM pg_class WHERE oid = 'public.fn06t'::regclass;
-[ RECORD 1 ]-------+------------------------------------------------------
relname | fn06t
relnamespace | 2200
reltype | 866874136
reloftype | 0
relowner | 10
relam | 0
relfilenode | 1092835324
reltablespace | 0
relpages | 218797
reltuples | 2.60181e+06
relallvisible | 192741
reltoastrelid | 866874160
relhasindex | t
relisshared | f
relpersistence | p
relkind | r
relnatts | 154
relchecks | 0
relhasoids | t
relhaspkey | t
relhasrules | f
relhastriggers | t
relhassubclass | f
relrowsecurity | f
relforcerowsecurity | f
relispopulated | t
relreplident | d
relispartition | f
relfrozenxid | 211279862
relminmxid | 122128619
relacl | {postgres=arwdDxt/postgres,usuarios=arwdDxt/postgres}
reloptions |
relpartbound |

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Peter Geoghegan 2018-04-11 03:01:21 Re: ERROR: found multixact from before relminmxid
Previous Message Andres Freund 2018-04-10 22:53:12 Re: ERROR: found multixact from before relminmxid