Re: New vacuum config to avoid anti wraparound vacuums

Hi Mok
> I have an idea for managing vacuums. When managing vacuums it can
sometimes be a struggle to manage the config settings for them, especially
when trying to avoid anti
> wraparound vacuums. Some tables are massive and needs scale factor
settings in the fractions of percent, sometimes, with no guarantee that
enough actions cross that
> threshold. Increasing the autovacuum_freeze_max_age to keep up with an
growing number of transactions across an instance is just kicking the can
down the road. Engineers run
> backfills that throw off any calculations you may use to work out these
scale factors and using the same values across an instance is too simple
while managing individually
> for tables can be too messy. Or you run a cron type job so you don't have
to think about it at all.
I think you can refer to these two parameters
https://www.postgresql.org/docs/18/runtime-config-vacuum.html#GUC-AUTOVACUUM-VACUUM-MAX-THRESHOLD
https://www.postgresql.org/docs/18/runtime-config-vacuum.html#
vacuum_freeze_table_age
If you're concerned about wraparound, you can reduce the value of
`VACUUM-VACUUM-MAX-THRESHOLD`,vacuum_freeze_table_age, Shouldn't you be
focusing on why the blocked table can't be vacuum-freeze?

Thanks

On Thu, Apr 23, 2026 at 10:10 PM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:

> On Fri, 24 Apr 2026 at 01:04, Mok <gurmokh(at)protonmail(dot)com> wrote:
> >
> > On Thursday, April 23rd, 2026 at 4:44 AM, David Rowley <
> dgrowleyml(at)gmail(dot)com> wrote:
> >
> > > On Thu, 23 Apr 2026 at 08:19, Mok <gurmokh(at)protonmail(dot)com> wrote:
> > > > For example, set to 0.8 a 'standard' vacuum would be triggered when
> the table reached 160million with a default 200million setting.
> > >
> > > If that's what you want, why wouldn't you set the
> > > autovacuum_freeze_max_age to 160million?
> >
> > Because that would trigger a 'to-prevent-wraparound' vacuum, which is
> what this change is trying to avoid.
>
> Yes, it would. Why do you want to prevent them? I believe a few people
> have been alarmed in the past about the "to prevent wraparound" text
> in pg_stat_activity or when they saw those words in the logs. The
> default 200 million autovacuum_freeze_max_age setting triggers an
> autovacuum when it's less than 10% of the way into exhausting the
> transaction space for the table. What you're proposing with an
> autovacuum_age_scale_factor of 0.1 sounds like it would result in an
> auto-vacuum when only 1% of the transaction ID space is consumed! I
> think you're under the false impression that these anti-wraparound
> vacuums are bad. They're not.
>
> There's some documentation that might be worthwhile reading in [1].
>
> David
>
> [1]
> https://www.postgresql.org/docs/18/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND
>
>
>