On April 10, 2018 11:51:40 PM PDT, Pavan Deolasee <pavan.deolasee@xxxxxxxxx> wrote: >On Wed, Apr 11, 2018 at 8:31 AM, Alexandre Arruda <adaldeia@xxxxxxxxx> >wrote: > >> 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. >> >> >I wonder if we're staring at some race condition in visibility map >where a >previous vacuum inadvertently skips a page because the visibility map >bit >is set, thus leaving behind an unfrozen multixid. The page then again >becomes !all_visible and the next vacuum then complains about the >unfrozen >multixid. Should be possible to write a query using page inspect and freespacemap to make sure they at least currently match. Andres -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
