Re: New vacuum config to avoid anti wraparound vacuums

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Mok <gurmokh(at)protonmail(dot)com>
Cc: "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: New vacuum config to avoid anti wraparound vacuums
Date: 2026-04-23 14:09:57
Message-ID: CAApHDvoa0ZwBjFYRypxHaqdFYwwDd6rTr5GWY8LASXr3kWY8Dg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexey Makhmutov 2026-04-23 14:17:51 Re: Two issues leading to discrepancies in FSM data on the standby server
Previous Message Marcos Pegoraro 2026-04-23 14:09:11 Re: Adding an explaining title to Notes on SGML