vacuum_defer_cleanup_age
Fact — official short description: “Number of transactions by which VACUUM and HOT cleanup should be deferred, if any.”
Identity
Lifecycle
| Fact | Value |
|---|---|
| First observed | PG9.0 (research boundary) |
| Present in | PG9.0–15 |
| Removed in | PG16 |
| Introduction commit | Not asserted: predates the PG9.0 research boundary |
| Commit date | — |
| Discussion | — |
Default history
| Versions | Raw boot_val |
Unit | Human value |
|---|---|---|---|
| PG9.0–15 | 0 |
— | 0 |
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.
Tuning advice
Advice. These are workload-specific starting points and must be validated with measurements.
| Workload | Guidance |
|---|---|
| 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. |
| 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. |
| Small nodes | Delete the obsolete setting and adopt the supported replacement directly; do not emulate legacy behavior in scripts without a demonstrated compatibility requirement. |
Pigsty
Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG15; this does not assert current Pigsty support for that historical or beta release.
| Template | Effective value | Versus upstream boot | Source expression |
|---|---|---|---|
| OLTP | Unmodified | — | — |
| OLAP | Unmodified | — | — |
| CRIT | 500000 |
different | 500000 |
| TINY | Unmodified | — | — |
Advice — pending human review. Fact from the current Pigsty template projection: OLTP: PG9.0–15 unmodified; OLAP: PG9.0–15 unmodified; CRIT: PG9.0–15 = 500000 (dcs); TINY: PG9.0–15 unmodified. Advice, pending human review — Editorial interpretation, pending human maintainer review: the override appears intended to historically protect CRIT standby reads by postponing cleanup, a policy that now requires migration; confirm it against the current Pigsty templates, hardware fixture, and operational guarantees before publication.
Common pitfalls
- 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.
Related parameters
synchronized_standby_slots · synchronous_standby_names · hot_standby · hot_standby_feedback · idle_replication_slot_timeout · max_active_replication_origins