MIME-Version: 1.0
References: <abGP87A3JPIXDG2I@nathan>
 <CAA5RZ0tWonKY=E5U51i-J8s2EcRoLqtUQyWv+pQ4_rjFKSn+AA@mail.gmail.com>
 <abGmNAVIPSqX124E@nathan>
 <CAA5RZ0sZE-gfJ0c9HJkOk9XeFQwZL2wuJwrtOX+ZfUBLDcpFMA@mail.gmail.com>
 <abMR6MQGQyyKWep4@nathan>
 <CAApHDvqHXYCb=x0hHeR1e21ksqFNk4q3_zoPk6V-LLu0VL491Q@mail.gmail.com>
 <abrOO8GCgkhMXvcq@nathan>
 <bff7dc5a-f839-449b-b56a-aab36cd3e39d@app.fastmail.com>
 <CAApHDvpnR5zKb7LSB0idj4RPsV+=Dhtk+c5H0cZ4evN2hFDwCQ@mail.gmail.com>
 <3ca1e398-c787-47e9-9afc-8e298b94dac0@app.fastmail.com>
 <abwbDTu6OO6Izp4o@nathan>
 <CAA5RZ0s7k6yve1Bq1OY+aXU3ifc_fvOiYkpE2VxwrUcHr2AtTg@mail.gmail.com>
In-Reply-To: 
 <CAA5RZ0s7k6yve1Bq1OY+aXU3ifc_fvOiYkpE2VxwrUcHr2AtTg@mail.gmail.com>
From: David Rowley <dgrowleyml@gmail.com>
Date: Fri, 20 Mar 2026 17:40:04 +1300
Message-ID: 
 <CAApHDvpvkKYB6z-i1kiO9iePF0fz18-CaS9DZEWnSx1eO0RGFQ@mail.gmail.com>
Subject: Re: another autovacuum scheduling thread
To: Sami Imseih <samimseih@gmail.com>
Cc: Nathan Bossart <nathandbossart@gmail.com>, Greg Burd <greg@burd.me>,
	Robert Haas <robertmhaas@gmail.com>, Robert Treat <rob@xzilla.net>,
	Jeremy Schneider <schneider@ardentperf.com>,
 pgsql-hackers <pgsql-hackers@postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
 <https://www.postgresql.org/message-id/CAApHDvpvkKYB6z-i1kiO9iePF0fz18-CaS9DZEWnSx1eO0RGFQ%40mail.gmail.com>
Precedence: bulk

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