Re: ERROR: found multixact from before relminmxid - Mailing list pgsql-general

From Alexandre Arruda
Subject Re: ERROR: found multixact from before relminmxid
Date
Msg-id CAGewt-trGM_xh-OZCf+xUs-x25ZFjCFkTXPLUCAGysH-Yq-DTw@mail.gmail.com
Whole thread Raw
In response to Re: ERROR: found multixact from before relminmxid  (Andres Freund <andres@anarazel.de>)
Responses Re: ERROR: found multixact from before relminmxid
List pgsql-general
2018-04-10 19:53 GMT-03:00 Andres Freund <andres@anarazel.de>:
> On 2018-04-10 08:31:20 -0300, Alexandre Arruda wrote:
>> 2018-04-09 23:51 GMT-03:00 Peter Geoghegan <pg@bowt.ie>:
>> > On Mon, Apr 9, 2018 at 6:56 PM, Alexandre Arruda <adaldeia@gmail.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        |


pgsql-general by date:

Previous
From: Andres Freund
Date:
Subject: Re: ERROR: found multixact from before relminmxid
Next
From: Peter Geoghegan
Date:
Subject: Re: ERROR: found multixact from before relminmxid