[PATCH] Auto vacuum should still run when clock is set back
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t53586psql -h localhost -U postgresBuilt from patchset v3 (message #3), September 20, 2026 at 02:00 PM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t53586_3 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t53586_3 && git checkout t53586_3Patchset v3 (message #3) is on t53586_3
If the system clock is set back a large amount after PostgreSQL starts up, auto vacuum may stop running for a very long time.
Attached is a small patch to reschedule the auto vacuum workers when the auto vacuum launcher detects that the current time is before the last time it was run.
I tested this with a script that simply updated a bunch of rows in a test table. Without the fix, the database files keep growing, with the fix, the storage used remains stable.
The patch is based on version f227b7b20c36b7348867eec48d539d28cfdf831c on the master branch of the git repo as of this morning.
Thank you,
Cliff Clark
On Tue, Mar 24, 2026 at 08:38:21PM +0000, Cliff Clark wrote:
Attached is a small patch to reschedule the auto vacuum workers when
the auto vacuum launcher detects that the current time is before the
last time it was run.
Do you mean clock changes, particularly due to Winter/Summer time
switches?
I tested this with a script that simply updated a bunch of rows in a
test table. Without the fix, the database files keep growing, with
the fix, the storage used remains stable.The patch is based on version
f227b7b20c36b7348867eec48d539d28cfdf831c on the master branch of the
git repo as of this morning.
You have not posted a patch, as far as I can see, so it is not really
possible to comment about your intention.
--
Michael
The clock changes are not due to DST, but the UTC system time. There was an NTP server on an offline network that went from 2019 to 2006 due to GPS week number rollover. The date being wrong did cause some problems, but nothing fatal, but several machines filled up their disk to the point of failure because autovacuum was no longer running.
I will attempt to attach the patch again.
________________________________________
From: Michael Paquier <michael@paquier.xyz>
Sent: Tuesday, March 24, 2026 18:55
To: Cliff Clark <Cliff_Clark@selinc.com>
Cc: pgsql-hackers@lists.postgresql.org <pgsql-hackers@lists.postgresql.org>
Subject: Re: [PATCH] Auto vacuum should still run when clock is set back
[You don't often get email from michael@paquier.xyz. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
[Caution - External]
Let me try this again:
From a7f04a8b5202eb794ed6846bb8fddccdeecd643c Mon Sep 17 00:00:00 2001
From: Cliff Clark <Cliff_Clark@selinc.com>
Date: Tue, 24 Mar 2026 11:32:43 -0700
Subject: [PATCH] Autovacuum should still run when clock is set back
Add code to detect when the clock was set back since the last autovacuum
launcher run. When this happens, rebuild the database list so that
autovacuum will continue to run.
---
src/backend/postmaster/autovacuum.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/src/backend/postmaster/autovacuum.c b/src/backend/postmaster/autovacuum.c
index 219673db930..9f2c6434802 100644
--- a/src/backend/postmaster/autovacuum.c
+++ b/src/backend/postmaster/autovacuum.c
@@ -377,6 +377,7 @@ void
AutoVacLauncherMain(const void *startup_data, size_t startup_data_len)
{
sigjmp_buf local_sigjmp_buf;
+ TimestampTz last_current_time;Assert(startup_data_len == 0);
@@ -568,6 +569,12 @@ AutoVacLauncherMain(const void *startup_data, size_t startup_data_len)
AutoVacuumShmem->av_launcherpid = MyProcPid;
+ /*
+ * Set the initial last run time to just before we build the worker
+ * schedule.
+ */
+ last_current_time = GetCurrentTimestamp();
+
/*
* Create the initial database list. The invariant we want this list to
* keep is that it's ordered by decreasing next_worker. As soon as an
@@ -649,6 +656,16 @@ AutoVacLauncherMain(const void *startup_data, size_t startup_data_len)
*/ current_time = GetCurrentTimestamp();
+ if (current_time < last_current_time)
+ {
+ /*
+ * The clock jumped backwards so reschedule the workers so that
+ * databases won't stop getting auto-vacuumed.
+ */
+ rebuild_database_list(InvalidOid);
+ }
+ last_current_time = current_time;
+
LWLockAcquire(AutovacuumLock, LW_SHARED); can_launch = av_worker_available();
--
2.43.0
________________________________________
From: Cliff Clark <Cliff_Clark@selinc.com>
Sent: Wednesday, March 25, 2026 9:21
To: Michael Paquier <michael@paquier.xyz>
Cc: pgsql-hackers@lists.postgresql.org <pgsql-hackers@lists.postgresql.org>
Subject: Re: [PATCH] Auto vacuum should still run when clock is set back
[Caution - External]
The clock changes are not due to DST, but the UTC system time. There was an NTP server on an offline network that went from 2019 to 2006 due to GPS week number rollover. The date being wrong did cause some problems, but nothing fatal, but several machines filled up their disk to the point of failure because autovacuum was no longer running.
I will attempt to attach the patch again.
________________________________________
From: Michael Paquier <michael@paquier.xyz>
Sent: Tuesday, March 24, 2026 18:55
To: Cliff Clark <Cliff_Clark@selinc.com>
Cc: pgsql-hackers@lists.postgresql.org <pgsql-hackers@lists.postgresql.org>
Subject: Re: [PATCH] Auto vacuum should still run when clock is set back
[You don't often get email from michael@paquier.xyz. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
[Caution - External]