On 2018-04-10 08:31:20 -0300, Alexandre Arruda wrote: > 2018-04-09 23:51 GMT-03:00 Peter Geoghegan <pg@xxxxxxx>: > > On Mon, Apr 9, 2018 at 6:56 PM, Alexandre Arruda <adaldeia@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxx say about your table? Could you post pg_controldata output and SELECT * FROM pg_class WHERE oid = 'public.fn06t'::regclass; ? Greetings, Andres Freund
