Re: mxid_score can become Infinity in pg_stat_autovacuum_scores

From: Sami Imseih <samimseih(at)gmail(dot)com>
To: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: mxid_score can become Infinity in pg_stat_autovacuum_scores
Date: 2026-06-12 20:37:41
Message-ID: CAA5RZ0sONu+T-HYRbWwnf_F7H8Y+cRfeEvmsi2J2W37NNea_xA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Attachment Content-Type Size
v1-0001-Correct-the-MultiXact-autovacuum-priority-score-w.patch application/octet-stream 3.5 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Zsolt Parragi 2026-06-12 20:39:27 Re: [PATCH v1] Add ssl_alt_cert_file/ssl_alt_key_file for dual RSA+ECDSA certificate support
Previous Message Ayush Tiwari 2026-06-12 20:05:23 Re: Modernizing pg_bsd_indent's error/warning reporting code