Re: MultiXactId wraparound and last aggressive vacuum time - Mailing list pgsql-general

From Michael Schanne
Subject Re: MultiXactId wraparound and last aggressive vacuum time
Date
Msg-id CAC_kJhQkzAgmDNjLaPoUAjfQhe8spJimiqKbBseQhSqsRV5aUA@mail.gmail.com
Whole thread Raw
In response to Re: MultiXactId wraparound and last aggressive vacuum time  (Michael Lewis <mlewis@entrata.com>)
Responses Re: MultiXactId wraparound and last aggressive vacuum time  (Jehan-Guillaume de Rorthais <jgdr@dalibo.com>)
List pgsql-general
After a closer reading of the documentation, it appears the database should stop accepting new transactions before a wraparound would ever occur.  If so, then the only possible explanations for this multixactid wraparound error would be data corruption, or a bug in postgresql.  The exact version I'm using is 9.6.10, which is quite a few versions behind the latest (9.6.21), but I skimmed through the release notes of the later versions and did not see any bugfixes in this area.  That would leave data corruption as the only explanation.  Is my reasoning correct here?  I'm willing to upgrade but I would need to justify it somehow, so if I am missing something please let me know.

On Tue, Mar 23, 2021 at 11:54 AM Michael Lewis <mlewis@entrata.com> wrote:
I don't believe you can determine a date/time that it happened, but querying the age of the table is simple to do and then you can compare that with the freeze age parameters. A periodic manual vacuum freeze may preclude the system ever needing to perform the emergency autovacuum freeze, and as an added benefit, index only scans would be more likely to be chosen since the visibility map would be updated and the regular autovacuum runs would be faster since they can skip frozen pages. I think that applies back to 9.6 at least. It's possible it got implemented in 10.

My caffeine hasn't fully kicked in yet and I am still a bit junior on this list, but I would hope and expect senior people to correct me if I have misunderstood or misrepresented things.

pgsql-general by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Is replacing transactions with CTE a good idea?
Next
From: Merlin Moncure
Date:
Subject: Re: Primary keys and composite unique keys(basic question)