On Wed, Apr 11, 2018 at 8:31 AM, Alexandre Arruda <adald...@gmail.com> wrote:
> 2018-04-10 19:09 GMT-03:00 Peter Geoghegan <p...@bowt.ie>: > > On Tue, Apr 10, 2018 at 4:31 AM, Alexandre Arruda <adald...@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. Thanks, Pavan -- Pavan Deolasee http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
