On Wed, Apr 11, 2018 at 8:31 AM, Alexandre Arruda <adaldeia@gmail.com> wrote:
2018-04-10 19:09 GMT-03:00 Peter Geoghegan <pg@bowt.ie>: > On Tue, Apr 10, 2018 at 4:31 AM, Alexandre Arruda <adaldeia@gmail.com> 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.
