On April 10, 2018 11:51:40 PM PDT, Pavan Deolasee <pavan.deolasee@gmail.com> wrote:
>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.
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.
