On Mon, Aug 31, 2026 at 10:23:26AM -0500, Nathan Bossart wrote:
> Claude noticed a corner case that needs handling. In short, if the freeze
> score weights are high enough, the pow() calls can have the opposite of the
> intended effect, since the freeze scores may be less than 1. Patch
> attached.
Hey Nathan, Bharath,
Confirmed, and +1 on the fix. I worked through the arithmetic and it's a
real oversight from d7965d65fc which I reviewed, apologies for not spotting
this back then.
It seems the trigger is that the weight divides effective_xid_failsafe_age:
if (autovacuum_freeze_score_weight > 1.0)
effective_xid_failsafe_age /= autovacuum_freeze_score_weight;
so a large enough weight can pull the failsafe threshold below
freeze_max_age, i.e. down into the region where
scores->xid = xid_age / freeze_max_age
is still < 1.0. Once we're there, pow(base < 1.0, exponent > 1.0) shrinks
the score, and shrinks it further as the exponent (age/1e8) grows. So a
table's score falls the moment it crosses into the failsafe range and keeps
falling as it ages, exactly backwards from the intent.
Reproducing your example numbers (freeze_max_age = 2000000000, weight = 10.0,
so effective_xid_failsafe_age = max(1.6e9, 2.1e9)/10 = 210M):
age before after
220M 0.077815 1.10
400M 0.016000 2.00
736M 0.006377 3.68
Before the patch all three sat below their unscaled scores and, worse,
decreased with age. After the patch the sub-1.0 bases skip pow() entirely
and fall back to ratio * weight (0.11*10 = 1.1, etc.), so they increase
monotonically again, as intended.
best,
-greg
