Re: Auto Vacuum Question

From: Michael Banck <mbanck(at)gmx(dot)net>
To: Murthy Nunna <mnunna(at)fnal(dot)gov>
Cc: "pgsql-admin(at)postgresql(dot)org" <pgsql-admin(at)postgresql(dot)org>
Subject: Re: Auto Vacuum Question
Date: 2023-10-16 21:40:12
Message-ID: 652dadbd.170a0220.1d68.00f9@mx.google.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

Hi,

On Mon, Oct 16, 2023 at 08:46:48PM +0000, Murthy Nunna wrote:
> It looks like the max value of autovacuum_freeze_max_age is 2 billion.
> I am wondering why anybody wants to change this setting to a lower number?

At a transaction age a bit above 2 billion, Postgres will stop accepting
connections and one needs to vacuum manually, usually resulting in a
long downtime.

So one needs some (or rather a lot of) daylight between the time
autovacuum decides to freeze a table and Postgres shutting down - it
could be that autovacuum is held back by long-running transactions or
unused replication slots or something.

I would consider autovacuum_freeze_max_age up to 1 billion mostly safe
(depending on the workload) and values up to 1.6 billion acceptable if
good monitoring is in place and everybody knows what is going on.

The other reason why want might not want to set
autovacuum_freeze_max_age so high is that the pg_xact and pg_commit_ts
sizes are proportional to autovacuum_freeze_max_age and take up more
space if autovacuum_freeze_max_age is higher, which might be problematic
if there is not a lot of storage present.

Michael

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Zhaoxun Yan 2023-10-17 06:55:35 postgresql lost connection to repmgr arbitrarily
Previous Message Scott Ribe 2023-10-16 21:04:13 Re: List Based Table Partitioning on non-Primary Key Columns