2018-04-10 19:09 GMT-03:00 Peter Geoghegan <pg@xxxxxxx>: > On Tue, Apr 10, 2018 at 4:31 AM, Alexandre Arruda <adaldeia@xxxxxxxxx> wrote: >> 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 > > Do you think that CLUSTER was run before regular VACUUM/autovacuum > showed this error, though? Yes, because the table is clustered in the old database and reclustered when it was reloaded in the version 10. But the table was not clustered again. > Have you noticed any data loss? Things look okay when you do your dump > + restore, right? The problem, as far as you know, is strictly that > CLUSTER + VACUUM refuse to finish/raise these multixactid errors? I did not see, apparently, any data loss. A dump/reload in fresh db shows the same data os production. I verify this by md5sum in genereted files created by a select statment (ordered by pkey) in both databases (prod and test). The problem is with regular vaccum that not complete. Cluster or vacuum FULL is a try to correct the problem. But I'm affraid if any data can be corrupted along time.
