Re: another autovacuum scheduling thread - Mailing list pgsql-hackers

From David Rowley
Subject Re: another autovacuum scheduling thread
Date
Msg-id CAApHDvpvkKYB6z-i1kiO9iePF0fz18-CaS9DZEWnSx1eO0RGFQ@mail.gmail.com
Whole thread
In response to Re: another autovacuum scheduling thread  (Sami Imseih <samimseih@gmail.com>)
Responses Re: another autovacuum scheduling thread
List pgsql-hackers
On Fri, 20 Mar 2026 at 17:22, Sami Imseih <samimseih@gmail.com> wrote:
> #5.
> +               if (autovacuum_freeze_score_weight > 1.0)
> +                       effective_xid_failsafe_age /=
> autovacuum_freeze_score_weight;
> +               if (autovacuum_multixact_freeze_score_weight > 1.0)
> +                       effective_mxid_failsafe_age /=
> autovacuum_multixact_freeze_score_weight;
> +
>
> Shouldn't this be "if (autovacuum_freeze_score_weight > 0.0)" ?
> A weight > 0 should always adjust the threshold, right? we should only
> prevent division by 0 here.

We really do want to ensure that tables are scaling very aggressively
when they reach the failsafe age. We don't want any quirky user
settings changing that. Prioritising anything else over a table at
failsafe age would be a very bad thing. The only point in doing what I
suggested was to allow users to give themselves more margin to get the
freezing done before failsafe age, certainly not less margin. In any
case, effective_xid_failsafe_age and effective_mxid_failsafe_age are
signed ints and default to 1.6 billion. There's just not enough
bit-space to divide them by any number much below 1.0 before they'll
wrap.

David



pgsql-hackers by date:

Previous
From: Sami Imseih
Date:
Subject: Re: another autovacuum scheduling thread
Next
From: Sami Imseih
Date:
Subject: Re: another autovacuum scheduling thread