Re: MultiXactId wraparound and last aggressive vacuum time

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(at)entrata(dot)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.
>
>>