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

> - 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

  1. Avoid division-by-zero when calculating autovacuum MXID score.

  2. Widen MultiXactOffset to 64 bits