Re: mxid_score can become Infinity in pg_stat_autovacuum_scores
Sami Imseih <samimseih@gmail.com>
From: Sami Imseih <samimseih@gmail.com>
To: Masahiko Sawada <sawada.mshk@gmail.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2026-06-12T20:37:41Z
Lists: pgsql-hackers
Attachments
- v1-0001-Correct-the-MultiXact-autovacuum-priority-score-w.patch (application/octet-stream) patch v1-0001
> - scores->mxid = (double) mxid_age / multixact_freeze_max_age; > + scores->mxid = (double) mxid_age / Max(multixact_freeze_max_age, 1); > Any thoughts on this? Hi, That is a good finding. I think what you are suggesting makes sense. If multixact_freeze_max_age is 0 (we have more than MULTIXACT_MEMBER_HIGH_THRESHOLD members, 4 billion) we then prioritize based on mxid_age, which will be high at that point for most cases and put that table high on the priority list. 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. See attached. -- 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