Re: mxid_score can become Infinity in pg_stat_autovacuum_scores

From: Sami Imseih <samimseih(at)gmail(dot)com>
To: Nathan Bossart <nathandbossart(at)gmail(dot)com>
Cc: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: mxid_score can become Infinity in pg_stat_autovacuum_scores
Date: 2026-06-16 16:21:57
Message-ID: CAA5RZ0tTJkFPA0=Wqs5hBLLA=h=F340VJok2PLTv3kZ4rL3C7w@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
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)

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Corey Huinker 2026-06-16 16:23:17 Re: Fix --missing-stats-only false positive for partitioned expression indexes
Previous Message Tom Lane 2026-06-16 16:20:12 Re: Direction for test frameworks: Perl TAP vs. Python/pytest