vacuum_defer_cleanup_age

Definition PG 15 manual

Specifies the number of transactions by which VACUUM and HOT updates will defer cleanup of dead row versions. The default is zero transactions, meaning that dead row versions can be removed as soon as possible, that is, as soon as they are no longer visible to any open transaction. You may wish to set this to a non-zero value on a primary server that is supporting hot standby servers, as described in Section 27.4. This allows more time for queries on the standby to complete without incurring conflicts due to early cleanup of rows. However, since the value is measured in terms of number of write transactions occurring on the primary server, it is difficult to predict just how much additional grace time will be made available to standby queries. This parameter can only be set in the postgresql.conf file or on the server command line.

You should also consider setting hot_standby_feedback on standby server(s) as an alternative to using this parameter.

This does not prevent cleanup of dead rows which have reached the age specified by old_snapshot_threshold.

How it works

Number of transactions by which VACUUM and HOT cleanup should be deferred, if any. The parameter still exists in PG15 and is no longer recognized from PG16. PostgreSQL 16 removed this transaction-count delay; use hot_standby_feedback, replication slots, and bounded standby-conflict policy according to the actual requirement.

This postponed removal of recently dead tuples by a fixed number of transactions on the primary, an imprecise way to protect standby queries. It could retain bloat without guaranteeing a wall-clock delay and was removed in PostgreSQL 16.

Before upgrading, inspect synchronized_standby_slots, synchronous_standby_names, hot_standby, remove the old name from configuration, ALTER SYSTEM, role/database settings, and automation templates, and verify the replacement before starting PG16 or later.

Operational considerations

Continuing to emit unknown parameter vacuum_defer_cleanup_age on PG16+.

Deleting only the setting name without migrating dependent application behavior.

Assuming the historical default equals the replacement mechanism's default.

Missing stale entries in ALTER SYSTEM, role/database settings, or automation templates.

Workload guidance

OLAP: Use the same migration path as OLTP, and also verify long batches, standbys, or large-object/extension workflows; removal of the old switch does not promise identical legacy behavior.

OLTP: Do not tune or continue emitting vacuum_defer_cleanup_age on PG16+. PostgreSQL 16 removed this transaction-count delay; use hot_standby_feedback, replication slots, and bounded standby-conflict policy according to the actual requirement. Scan every configuration layer and regression-test the application before upgrade.

SMALL: Delete the obsolete setting and adopt the supported replacement directly; do not emulate legacy behavior in scripts without a demonstrated compatibility requirement.