Re: New vacuum config to avoid anti wraparound vacuums - Mailing list pgsql-hackers

From Nathan Bossart
Subject Re: New vacuum config to avoid anti wraparound vacuums
Date
Msg-id afFs-Mv4QjpOGB9m@nathan
Whole thread
In response to Re: New vacuum config to avoid anti wraparound vacuums  (Gurmokh <gurmokh@protonmail.com>)
List pgsql-hackers
On Tue, Apr 28, 2026 at 09:21:35PM +0000, Gurmokh wrote:
> The config parameters in [1] autovacuum_vacuum_threshold,
> autovacuum_vacuum_insert_threshold, autovacuum_vacuum_scale_factor,
> autovacuum_vacuum_insert_scale_factor and autovacuum_vacuum_max_threshold
> rely on regular activity to trigger autovacuums. However it is entirely
> plausible that these can be configured with values that are not sensitive
> enough and a table breaches the autovacuum_freeze_max_age triggering an
> aggressive vacuum to prevent wraparound before any less aggressive
> vacuums can be triggered.
> 
> In my experience I have seen tables that have significant activity and
> still not meet the criteria to trigger an autovacuum and subsequently age
> out. I have seen production systems slow to a grind waiting for these to
> complete.
> 
> What I'm suggesting here is to have a configurable parameter that
> represents a value as a percentage of autovacuum_freeze_max_age that
> would enable a table to be autovacuumed before a vacuum to prevent
> wraparound is triggered if none of the above conditions are met.

So your new parameter is meant to trigger non-aggressive vacuums in hopes
that it might advance relfrozenxid and avoid an upcoming aggressive vacuum.
Do I have that right?

If so, I'm not sure that such a feature will make a tremendous amount of
difference.  Non-aggressive vacuums can only advance relfrozenxid (thus
preventing an imminent aggressive vacuum) if they don't skip any pages and
are able to obtain cleanup locks for the relevant buffers, but page
skipping and conditional locking seem like key features that would make a
non-aggressive autovacuum less disruptive.  I think there's a good chance
that even with your parameter, a preemptive non-aggressive vacuum would be
followed by an aggressive one shortly afterwards.

Perhaps there are other reasons prioritizing a non-aggressive autovacuum
would help, but it's hard to tell from the details you've shared thus far.
Would you mind elaborating on what you are seeing that is causing your
servers to "slow to a grind"?

-- 
nathan



pgsql-hackers by date:

Previous
From: Bharath Rupireddy
Date:
Subject: Re: Add tests for concurrent DML retry paths in logical replication apply
Next
From: shveta malik
Date:
Subject: Re: Fix race condition in pg_get_publication_tables with concurrent DROP TABLE