Re: mxid_score can become Infinity in pg_stat_autovacuum_scores
Sami Imseih <samimseih@gmail.com>
From: Sami Imseih <samimseih@gmail.com>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>, Masahiko Sawada <sawada.mshk@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2026-06-16T16:21:57Z
Lists: pgsql-hackers
> > I do think we need to mention in the docs also about this caveat > > in scoring, so users of pg_stat_autovacuum_scores are not surprised. > > As member space usage grows between 2 billion and 4 billion, the > > score ramps up gradually, but once members reach 4 billion the effective freeze > > max age drops to 0 and the score jumps to mxid_age itself, > > which could be in the hundreds of millions. > > I'm -0.2 for documenting this case. I understand that users might be > confused about the results in such extreme situations, but I worry more > about users being confused by the excruciating detail of the documentation. > The existing docs are already quite complex, but I did spent a lot of time > trying to find the right balance of detail and accessibility when > committing. I think this particular scenario is very clear to explain just like how we explain the failsafe scenario. Also, the suggested docs in the view link to the already existing detailed explanation of this behavior. More generally, I think anytime there is a drastic change in a score, like jumping from a gradually ramping value around 1.x to suddenly hundreds of millions, that's something worth calling out in the docs. Users monitoring pg_stat_autovacuum_scores will notice that jump and want to understand why it happened. -- Sami Imseih Amazon Web Services (AWS)
Commits
-
Avoid division-by-zero when calculating autovacuum MXID score.
- 1f2297b54879 19 (unreleased) landed
-
Widen MultiXactOffset to 64 bits
- bd8d9c9bdfa0 19 (unreleased) cited