Vacuuming

• 1: autovacuum
• 2: autovacuum_analyze_scale_factor
• 3: autovacuum_analyze_score_weight
• 4: autovacuum_analyze_threshold
• 5: autovacuum_freeze_max_age
• 6: autovacuum_freeze_score_weight
• 7: autovacuum_max_parallel_workers
• 8: autovacuum_max_workers
• 9: autovacuum_multixact_freeze_max_age
• 10: autovacuum_multixact_freeze_score_weight
• 11: autovacuum_naptime
• 12: autovacuum_vacuum_cost_delay
• 13: autovacuum_vacuum_cost_limit
• 14: autovacuum_vacuum_insert_scale_factor
• 15: autovacuum_vacuum_insert_score_weight
• 16: autovacuum_vacuum_insert_threshold
• 17: autovacuum_vacuum_max_threshold
• 18: autovacuum_vacuum_scale_factor
• 19: autovacuum_vacuum_score_weight
• 20: autovacuum_vacuum_threshold
• 21: autovacuum_worker_slots
• 22: vacuum_cost_delay
• 23: vacuum_cost_limit
• 24: vacuum_cost_page_dirty
• 25: vacuum_cost_page_hit
• 26: vacuum_cost_page_miss
• 27: vacuum_failsafe_age
• 28: vacuum_freeze_min_age
• 29: vacuum_freeze_table_age
• 30: vacuum_max_eager_freeze_failure_rate
• 31: vacuum_multixact_failsafe_age
• 32: vacuum_multixact_freeze_min_age
• 33: vacuum_multixact_freeze_table_age
• 34: vacuum_truncate

1 - autovacuum

Identity

Lifecycle

Default history

How it works

When enabled, one launcher coordinates worker processes across databases. Workers use cumulative table-change statistics, so track_counts must also be enabled, and they run VACUUM or ANALYZE when a table crosses the relevant thresholds.

Ordinary vacuum triggers react to inserted, updated, and deleted tuples. Separately, PostgreSQL can launch anti-wraparound autovacuums even when this switch is off, because allowing old transaction IDs or multixact IDs to wrap would threaten correctness.

Most trigger and cost settings can be overridden per table through storage parameters. Temporary tables are outside autovacuum’s reach, and partitioned parent tables can still need manual ANALYZE even though their partitions are processed normally.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Turning it off does not disable emergency anti-wraparound vacuuming.
• track_counts must be on for ordinary autovacuum decisions to work.
• Long transactions and stale replication slots can prevent cleanup even when workers run successfully.
• Autovacuum does not analyze partitioned parent tables solely because their partitions changed.
• Temporary tables require maintenance from the owning session.

Related parameters

autovacuum_max_workers · autovacuum_naptime · autovacuum_vacuum_scale_factor · autovacuum_analyze_scale_factor · autovacuum_freeze_max_age · track_counts

References

• PostgreSQL 19 Beta 3 — autovacuum
• PostgreSQL 18: Routine Vacuuming and the Autovacuum Daemon
• PostgreSQL 19 release notes
• Machine-readable GUC export

2 - autovacuum_analyze_scale_factor

Identity

Lifecycle

Default history

How it works

Number of tuple inserts, updates, or deletes prior to analyze as a fraction of reltuples. A configuration reload applies a new value; existing work already in flight is not retroactively changed.

The automatic-ANALYZE trigger is autovacuum_analyze_threshold plus autovacuum_analyze_scale_factor times pg_class.reltuples; inserts, updates, and deletes feed the cumulative counter. Per-table storage parameters can override the global values, and the statistics are eventually consistent estimates.

Monitor and change autovacuum_analyze_scale_factor together with autovacuum_analyze_threshold, default_statistics_target, track_counts. Validate on the relevant server role and real workload, then use its sighup context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Changing the global value while a table storage parameter overrides it.
• Treating reltuples and cumulative change statistics as exact real-time counts.
• Blaming a threshold without checking long transactions, replication slots, and worker saturation.
• Buying short-term quiet by deferring maintenance until wraparound failsafe activates.

Related parameters

autovacuum_analyze_threshold · default_statistics_target · track_counts · autovacuum · autovacuum_freeze_max_age · autovacuum_max_workers

References

• PostgreSQL 19 Beta 3 — autovacuum_analyze_scale_factor
• PostgreSQL 19 release notes
• Machine-readable GUC export

3 - autovacuum_analyze_score_weight

Identity

Lifecycle

Default history

How it works

PostgreSQL describes autovacuum_analyze_score_weight as follows: “Scaling factor of analyze score for autovacuum prioritization.” A configuration reload applies the value to the server without a full restart. The atlas measures it in PG19 Beta 3; boot_val is the compiled or initialized baseline, not proof of a running cluster’s effective setting.

PostgreSQL 19 scores every eligible table and sorts work by the maximum weighted component. This parameter multiplies the ANALYZE change pressure component: values above 1 raise its scheduling influence, values between 0 and 1 reduce it, and setting every score weight to 0 restores the pre-19 catalog-order strategy. pg_stat_autovacuum_scores exposes the components for inspection.

Read it together with autovacuum_freeze_score_weight, autovacuum_multixact_freeze_score_weight, autovacuum_vacuum_score_weight, autovacuum_vacuum_insert_score_weight. Check SHOW and pg_settings on the target server, verify the source and pending_restart fields, and compare workload, logs, and resource metrics before and after any change.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Treating the measured boot_val for autovacuum_analyze_score_weight as proof of the effective value on an initialized or managed cluster.
• Applying a change as though it were immediate while pg_settings reports sighup context.
• Changing this setting in isolation without checking the linked limits, observability, and rollback path.
• Depending on beta behavior in production without retesting the PostgreSQL 19 final release.

Related parameters

autovacuum_freeze_score_weight · autovacuum_multixact_freeze_score_weight · autovacuum_vacuum_score_weight · autovacuum_vacuum_insert_score_weight · autovacuum_max_workers · autovacuum_naptime

References

• PostgreSQL 19 Beta 3 — autovacuum_analyze_score_weight
• PostgreSQL 19 release notes
• Machine-readable GUC export

4 - autovacuum_analyze_threshold

Identity

Lifecycle

Default history

How it works

Minimum number of tuple inserts, updates, or deletes prior to analyze. A configuration reload applies a new value; existing work already in flight is not retroactively changed.

The automatic-ANALYZE trigger is autovacuum_analyze_threshold plus autovacuum_analyze_scale_factor times pg_class.reltuples; inserts, updates, and deletes feed the cumulative counter. Per-table storage parameters can override the global values, and the statistics are eventually consistent estimates.

Monitor and change autovacuum_analyze_threshold together with autovacuum_analyze_scale_factor, default_statistics_target, track_counts. Validate on the relevant server role and real workload, then use its sighup context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Changing the global value while a table storage parameter overrides it.
• Treating reltuples and cumulative change statistics as exact real-time counts.
• Blaming a threshold without checking long transactions, replication slots, and worker saturation.
• Buying short-term quiet by deferring maintenance until wraparound failsafe activates.

Related parameters

autovacuum_analyze_scale_factor · default_statistics_target · track_counts · autovacuum · autovacuum_freeze_max_age · autovacuum_max_workers

References

• PostgreSQL 19 Beta 3 — autovacuum_analyze_threshold
• PostgreSQL 19 release notes
• Machine-readable GUC export

5 - autovacuum_freeze_max_age

Identity

Lifecycle

Default history

How it works

Age at which to autovacuum a table to prevent transaction ID wraparound. The value is fixed when the server starts, so changing it requires a restart.

Reaching the max age forces an aggressive autovacuum even if ordinary autovacuum is disabled; a per-table override can only lower the global ceiling. Safety must be assessed across every database/table age together with long transactions and replication slots.

Monitor and change autovacuum_freeze_max_age together with vacuum_freeze_min_age, vacuum_freeze_table_age, vacuum_failsafe_age. Validate on the relevant server role and real workload, then use its postmaster context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Converting transaction age to days without using the actual transaction rate.
• Raising the ceiling to hide blocked or underprovisioned vacuum.
• Monitoring only the current database instead of every database and table.
• Changing the global value while a table storage parameter overrides it.
• Treating reltuples and cumulative change statistics as exact real-time counts.

Related parameters

vacuum_freeze_min_age · vacuum_freeze_table_age · vacuum_failsafe_age · autovacuum_multixact_freeze_max_age · vacuum_multixact_freeze_min_age · vacuum_multixact_freeze_table_age

References

• PostgreSQL 19 Beta 3 — autovacuum_freeze_max_age
• PostgreSQL 19 release notes
• Machine-readable GUC export

6 - autovacuum_freeze_score_weight

Identity

Lifecycle

Default history

How it works

PostgreSQL describes autovacuum_freeze_score_weight as follows: “Scaling factor of freeze score for autovacuum prioritization.” A configuration reload applies the value to the server without a full restart. The atlas measures it in PG19 Beta 3; boot_val is the compiled or initialized baseline, not proof of a running cluster’s effective setting.

PostgreSQL 19 scores every eligible table and sorts work by the maximum weighted component. This parameter multiplies the transaction-ID freeze age component: values above 1 raise its scheduling influence, values between 0 and 1 reduce it, and setting every score weight to 0 restores the pre-19 catalog-order strategy. pg_stat_autovacuum_scores exposes the components for inspection.

Read it together with autovacuum_multixact_freeze_score_weight, autovacuum_vacuum_score_weight, autovacuum_vacuum_insert_score_weight, autovacuum_analyze_score_weight. Check SHOW and pg_settings on the target server, verify the source and pending_restart fields, and compare workload, logs, and resource metrics before and after any change.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Treating the measured boot_val for autovacuum_freeze_score_weight as proof of the effective value on an initialized or managed cluster.
• Applying a change as though it were immediate while pg_settings reports sighup context.
• Changing this setting in isolation without checking the linked limits, observability, and rollback path.
• Depending on beta behavior in production without retesting the PostgreSQL 19 final release.

Related parameters

autovacuum_multixact_freeze_score_weight · autovacuum_vacuum_score_weight · autovacuum_vacuum_insert_score_weight · autovacuum_analyze_score_weight · autovacuum_max_workers · autovacuum_naptime

References

• PostgreSQL 19 Beta 3 — autovacuum_freeze_score_weight
• PostgreSQL 19 release notes
• Machine-readable GUC export

7 - autovacuum_max_parallel_workers

Identity

Lifecycle

Default history

How it works

PostgreSQL describes autovacuum_max_parallel_workers as follows: “Maximum number of parallel workers that can be used by a single autovacuum worker.” A configuration reload applies the value to the server without a full restart. The atlas measures it in PG19 Beta 3; boot_val is the compiled or initialized baseline, not proof of a running cluster’s effective setting.

The limit applies per autovacuum worker and only to index vacuuming and index-cleanup phases. Zero disables parallel autovacuum; the actual count is also capped by max_parallel_workers, while each participating worker consumes CPU and maintenance memory.

Read it together with autovacuum_max_workers, autovacuum_worker_slots, max_parallel_workers, maintenance_work_mem. Check SHOW and pg_settings on the target server, verify the source and pending_restart fields, and compare workload, logs, and resource metrics before and after any change.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Treating the measured boot_val for autovacuum_max_parallel_workers as proof of the effective value on an initialized or managed cluster.
• Applying a change as though it were immediate while pg_settings reports sighup context.
• Changing this setting in isolation without checking the linked limits, observability, and rollback path.
• Depending on beta behavior in production without retesting the PostgreSQL 19 final release.

Related parameters

autovacuum_max_workers · autovacuum_worker_slots · max_parallel_workers · maintenance_work_mem · autovacuum_work_mem

References

• PostgreSQL 19 Beta 3 — autovacuum_max_parallel_workers
• PostgreSQL 19 release notes
• Machine-readable GUC export

8 - autovacuum_max_workers

Identity

Lifecycle

Default history

How it works

The launcher starts workers across databases up to this limit. A worker can process one table at a time, several workers may operate in the same database, and these processes do not consume max_connections slots.

In PostgreSQL 18, autovacuum workers are drawn from autovacuum_worker_slots, so setting this value above the slot count has no effect. The local fact matrix also records a context change: PG10-17 required server start, while PG18 makes the setting reloadable.

Autovacuum cost limits are normally balanced among active workers. Raising only the worker count therefore improves concurrency and queueing, but does not necessarily multiply the total permitted maintenance I/O rate.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• A value above autovacuum_worker_slots is ineffective on PostgreSQL 18.
• More workers can amplify I/O latency even when backlog improves.
• Raising workers alone may not raise aggregate cost-based vacuum throughput.
• A few very large tables can occupy all workers and delay unrelated databases.
• Changing it on PG10-17 requires restart; PG18 behavior is reloadable.

Related parameters

autovacuum · autovacuum_worker_slots · autovacuum_naptime · autovacuum_vacuum_cost_limit · autovacuum_vacuum_cost_delay · max_worker_processes

References

• PostgreSQL 19 Beta 3 — autovacuum_max_workers
• PostgreSQL 18: The Autovacuum Daemon
• PostgreSQL 19 release notes
• Machine-readable GUC export

9 - autovacuum_multixact_freeze_max_age

Identity

Lifecycle

Default history

How it works

Multixact age at which to autovacuum a table to prevent multixact wraparound. The value is fixed when the server starts, so changing it requires a restart.

Reaching the max age forces an aggressive autovacuum even if ordinary autovacuum is disabled; a per-table override can only lower the global ceiling. Safety must be assessed across every database/table age together with long transactions and replication slots.

Monitor and change autovacuum_multixact_freeze_max_age together with autovacuum_freeze_max_age, vacuum_freeze_min_age, vacuum_freeze_table_age. Validate on the relevant server role and real workload, then use its postmaster context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Ignoring MultiXact member storage pressure, which can force work earlier.
• Assuming XID-age monitoring also covers MXID age.
• Raising the ceiling while long-lived row locks keep generating old multixacts.
• Changing the global value while a table storage parameter overrides it.
• Treating reltuples and cumulative change statistics as exact real-time counts.

Related parameters

autovacuum_freeze_max_age · vacuum_freeze_min_age · vacuum_freeze_table_age · vacuum_failsafe_age · vacuum_multixact_freeze_min_age · vacuum_multixact_freeze_table_age

References

• PostgreSQL 19 Beta 3 — autovacuum_multixact_freeze_max_age
• PostgreSQL 19 release notes
• Machine-readable GUC export

10 - autovacuum_multixact_freeze_score_weight

Identity

Lifecycle

Default history

How it works

PostgreSQL describes autovacuum_multixact_freeze_score_weight as follows: “Scaling factor of multixact freeze score for autovacuum prioritization.” A configuration reload applies the value to the server without a full restart. The atlas measures it in PG19 Beta 3; boot_val is the compiled or initialized baseline, not proof of a running cluster’s effective setting.

PostgreSQL 19 scores every eligible table and sorts work by the maximum weighted component. This parameter multiplies the MultiXact freeze age component: values above 1 raise its scheduling influence, values between 0 and 1 reduce it, and setting every score weight to 0 restores the pre-19 catalog-order strategy. pg_stat_autovacuum_scores exposes the components for inspection.

Read it together with autovacuum_freeze_score_weight, autovacuum_vacuum_score_weight, autovacuum_vacuum_insert_score_weight, autovacuum_analyze_score_weight. Check SHOW and pg_settings on the target server, verify the source and pending_restart fields, and compare workload, logs, and resource metrics before and after any change.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Treating the measured boot_val for autovacuum_multixact_freeze_score_weight as proof of the effective value on an initialized or managed cluster.
• Applying a change as though it were immediate while pg_settings reports sighup context.
• Changing this setting in isolation without checking the linked limits, observability, and rollback path.
• Depending on beta behavior in production without retesting the PostgreSQL 19 final release.

Related parameters

autovacuum_freeze_score_weight · autovacuum_vacuum_score_weight · autovacuum_vacuum_insert_score_weight · autovacuum_analyze_score_weight · autovacuum_max_workers · autovacuum_naptime

References

• PostgreSQL 19 Beta 3 — autovacuum_multixact_freeze_score_weight
• PostgreSQL 19 release notes
• Machine-readable GUC export

11 - autovacuum_naptime

Identity

Lifecycle

Default history

How it works

Time to sleep between autovacuum runs. A configuration reload applies a new value; existing work already in flight is not retroactively changed.

The launcher aims to start work in each database once per interval; with N databases, launch attempts are spread at roughly naptime/N. It is not a fixed per-table polling period, and worker availability plus long-running jobs can add delay.

Monitor and change autovacuum_naptime together with autovacuum, autovacuum_max_workers, autovacuum_worker_slots. Validate on the relevant server role and real workload, then use its sighup context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Changing the global value while a table storage parameter overrides it.
• Treating reltuples and cumulative change statistics as exact real-time counts.
• Blaming a threshold without checking long transactions, replication slots, and worker saturation.
• Buying short-term quiet by deferring maintenance until wraparound failsafe activates.

Related parameters

autovacuum · autovacuum_max_workers · autovacuum_worker_slots · autovacuum_work_mem · track_counts · autovacuum_analyze_scale_factor

References

• PostgreSQL 19 Beta 3 — autovacuum_naptime
• PostgreSQL 19 release notes
• Machine-readable GUC export

12 - autovacuum_vacuum_cost_delay

Identity

Lifecycle

Default history

How it works

Vacuum cost delay in milliseconds, for autovacuum. A configuration reload applies a new value; existing work already in flight is not retroactively changed.

These values govern cost throttling for autovacuum workers; -1 inherits vacuum_cost_delay or vacuum_cost_limit respectively. With multiple active workers, the autovacuum cost budget is balanced among them, so a per-worker reading is not simply multiplied by concurrency.

Monitor and change autovacuum_vacuum_cost_delay together with vacuum_cost_delay, vacuum_cost_limit, vacuum_cost_page_hit. Validate on the relevant server role and real workload, then use its sighup context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Changing the global value while a table storage parameter overrides it.
• Treating reltuples and cumulative change statistics as exact real-time counts.
• Blaming a threshold without checking long transactions, replication slots, and worker saturation.
• Buying short-term quiet by deferring maintenance until wraparound failsafe activates.

Related parameters

vacuum_cost_delay · vacuum_cost_limit · vacuum_cost_page_hit · vacuum_cost_page_miss · vacuum_cost_page_dirty · autovacuum_vacuum_cost_limit

References

• PostgreSQL 19 Beta 3 — autovacuum_vacuum_cost_delay
• PostgreSQL 19 release notes
• Machine-readable GUC export

13 - autovacuum_vacuum_cost_limit

Identity

Lifecycle

Default history

How it works

Vacuum cost amount available before napping, for autovacuum. A configuration reload applies a new value; existing work already in flight is not retroactively changed.

These values govern cost throttling for autovacuum workers; -1 inherits vacuum_cost_delay or vacuum_cost_limit respectively. With multiple active workers, the autovacuum cost budget is balanced among them, so a per-worker reading is not simply multiplied by concurrency.

Monitor and change autovacuum_vacuum_cost_limit together with vacuum_cost_delay, vacuum_cost_limit, vacuum_cost_page_hit. Validate on the relevant server role and real workload, then use its sighup context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Changing the global value while a table storage parameter overrides it.
• Treating reltuples and cumulative change statistics as exact real-time counts.
• Blaming a threshold without checking long transactions, replication slots, and worker saturation.
• Buying short-term quiet by deferring maintenance until wraparound failsafe activates.

Related parameters

vacuum_cost_delay · vacuum_cost_limit · vacuum_cost_page_hit · vacuum_cost_page_miss · vacuum_cost_page_dirty · autovacuum_vacuum_cost_delay

References

• PostgreSQL 19 Beta 3 — autovacuum_vacuum_cost_limit
• PostgreSQL 19 release notes
• Machine-readable GUC export

14 - autovacuum_vacuum_insert_scale_factor

Identity

Lifecycle

Default history

How it works

Number of tuple inserts prior to vacuum as a fraction of reltuples. A configuration reload applies a new value; existing work already in flight is not retroactively changed.

For insert-heavy tables the trigger is the insert threshold plus insert scale factor times reltuples times the fraction not all-frozen. Such vacuuming can advance visibility/freeze state even without dead tuples and reduce later aggressive-vacuum work.

Monitor and change autovacuum_vacuum_insert_scale_factor together with autovacuum_vacuum_threshold, autovacuum_vacuum_scale_factor, autovacuum_vacuum_max_threshold. Validate on the relevant server role and real workload, then use its sighup context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Changing the global value while a table storage parameter overrides it.
• Treating reltuples and cumulative change statistics as exact real-time counts.
• Blaming a threshold without checking long transactions, replication slots, and worker saturation.
• Buying short-term quiet by deferring maintenance until wraparound failsafe activates.

Related parameters

autovacuum_vacuum_threshold · autovacuum_vacuum_scale_factor · autovacuum_vacuum_max_threshold · autovacuum_vacuum_insert_threshold · autovacuum · autovacuum_analyze_scale_factor

References

• PostgreSQL 19 Beta 3 — autovacuum_vacuum_insert_scale_factor
• PostgreSQL 19 release notes
• Machine-readable GUC export

15 - autovacuum_vacuum_insert_score_weight

Identity

Lifecycle

Default history

How it works

PostgreSQL describes autovacuum_vacuum_insert_score_weight as follows: “Scaling factor of vacuum insert score for autovacuum prioritization.” A configuration reload applies the value to the server without a full restart. The atlas measures it in PG19 Beta 3; boot_val is the compiled or initialized baseline, not proof of a running cluster’s effective setting.

PostgreSQL 19 scores every eligible table and sorts work by the maximum weighted component. This parameter multiplies the insert-driven vacuum pressure component: values above 1 raise its scheduling influence, values between 0 and 1 reduce it, and setting every score weight to 0 restores the pre-19 catalog-order strategy. pg_stat_autovacuum_scores exposes the components for inspection.

Read it together with autovacuum_freeze_score_weight, autovacuum_multixact_freeze_score_weight, autovacuum_vacuum_score_weight, autovacuum_analyze_score_weight. Check SHOW and pg_settings on the target server, verify the source and pending_restart fields, and compare workload, logs, and resource metrics before and after any change.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Treating the measured boot_val for autovacuum_vacuum_insert_score_weight as proof of the effective value on an initialized or managed cluster.
• Applying a change as though it were immediate while pg_settings reports sighup context.
• Changing this setting in isolation without checking the linked limits, observability, and rollback path.
• Depending on beta behavior in production without retesting the PostgreSQL 19 final release.

Related parameters

autovacuum_freeze_score_weight · autovacuum_multixact_freeze_score_weight · autovacuum_vacuum_score_weight · autovacuum_analyze_score_weight · autovacuum_max_workers · autovacuum_naptime

References

• PostgreSQL 19 Beta 3 — autovacuum_vacuum_insert_score_weight
• PostgreSQL 19 release notes
• Machine-readable GUC export

16 - autovacuum_vacuum_insert_threshold

Identity

Lifecycle

Default history

How it works

Minimum number of tuple inserts prior to vacuum. A configuration reload applies a new value; existing work already in flight is not retroactively changed.

For insert-heavy tables the trigger is the insert threshold plus insert scale factor times reltuples times the fraction not all-frozen. Such vacuuming can advance visibility/freeze state even without dead tuples and reduce later aggressive-vacuum work.

Monitor and change autovacuum_vacuum_insert_threshold together with autovacuum_vacuum_threshold, autovacuum_vacuum_scale_factor, autovacuum_vacuum_max_threshold. Validate on the relevant server role and real workload, then use its sighup context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Changing the global value while a table storage parameter overrides it.
• Treating reltuples and cumulative change statistics as exact real-time counts.
• Blaming a threshold without checking long transactions, replication slots, and worker saturation.
• Buying short-term quiet by deferring maintenance until wraparound failsafe activates.

Related parameters

autovacuum_vacuum_threshold · autovacuum_vacuum_scale_factor · autovacuum_vacuum_max_threshold · autovacuum_vacuum_insert_scale_factor · autovacuum · autovacuum_analyze_scale_factor

References

• PostgreSQL 19 Beta 3 — autovacuum_vacuum_insert_threshold
• PostgreSQL 19 release notes
• Machine-readable GUC export

17 - autovacuum_vacuum_max_threshold

Identity

Lifecycle

Default history

How it works

Maximum number of tuple updates or deletes prior to vacuum. A configuration reload applies a new value; existing work already in flight is not retroactively changed.

The ordinary automatic-vacuum threshold is the base term plus scale factor times reltuples, capped by autovacuum_vacuum_max_threshold from PG18. It reacts to dead tuples from updates/deletes, permits per-table overrides, and is separate from mandatory anti-wraparound vacuuming.

Monitor and change autovacuum_vacuum_max_threshold together with autovacuum_vacuum_threshold, autovacuum_vacuum_scale_factor, autovacuum_vacuum_insert_threshold. Validate on the relevant server role and real workload, then use its sighup context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Changing the global value while a table storage parameter overrides it.
• Treating reltuples and cumulative change statistics as exact real-time counts.
• Blaming a threshold without checking long transactions, replication slots, and worker saturation.
• Buying short-term quiet by deferring maintenance until wraparound failsafe activates.

Related parameters

autovacuum_vacuum_threshold · autovacuum_vacuum_scale_factor · autovacuum_vacuum_insert_threshold · autovacuum_vacuum_insert_scale_factor · autovacuum · autovacuum_analyze_scale_factor

References

• PostgreSQL 19 Beta 3 — autovacuum_vacuum_max_threshold
• PostgreSQL 19 release notes
• Machine-readable GUC export

18 - autovacuum_vacuum_scale_factor

Identity

Lifecycle

Default history

How it works

The core trigger is the base threshold plus this factor multiplied by pg_class.reltuples, an approximate row count. In PostgreSQL 18 the result is also capped by autovacuum_vacuum_max_threshold.

This trigger counts tuples made obsolete by UPDATE or DELETE; insert-driven vacuuming has its own threshold and scale factor. Anti-wraparound vacuuming is governed by transaction-age rules and can run independently of this setting.

A table-level autovacuum_vacuum_scale_factor storage parameter overrides the global value, which is often preferable when table sizes and update rates vary widely.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• A percentage that looks small can still represent millions of dead tuples on a large table.
• Lowering the factor globally can create continuous I/O pressure across many tables.
• It does not control insert-triggered vacuuming or anti-wraparound vacuuming.
• reltuples is an estimate, so the trigger is not an exact dead-row percentage.
• Table storage parameters can silently make the global value irrelevant for that table.

Related parameters

autovacuum_vacuum_threshold · autovacuum_vacuum_max_threshold · autovacuum_vacuum_insert_scale_factor · autovacuum_analyze_scale_factor · autovacuum_naptime · autovacuum_freeze_max_age

References

• PostgreSQL 19 Beta 3 — autovacuum_vacuum_scale_factor
• PostgreSQL 18: Autovacuum trigger formulas
• PostgreSQL 19 release notes
• Machine-readable GUC export

19 - autovacuum_vacuum_score_weight

Identity

Lifecycle

Default history

How it works

PostgreSQL describes autovacuum_vacuum_score_weight as follows: “Scaling factor of vacuum score for autovacuum prioritization.” A configuration reload applies the value to the server without a full restart. The atlas measures it in PG19 Beta 3; boot_val is the compiled or initialized baseline, not proof of a running cluster’s effective setting.

PostgreSQL 19 scores every eligible table and sorts work by the maximum weighted component. This parameter multiplies the updated/deleted-tuple vacuum pressure component: values above 1 raise its scheduling influence, values between 0 and 1 reduce it, and setting every score weight to 0 restores the pre-19 catalog-order strategy. pg_stat_autovacuum_scores exposes the components for inspection.

Read it together with autovacuum_freeze_score_weight, autovacuum_multixact_freeze_score_weight, autovacuum_vacuum_insert_score_weight, autovacuum_analyze_score_weight. Check SHOW and pg_settings on the target server, verify the source and pending_restart fields, and compare workload, logs, and resource metrics before and after any change.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Treating the measured boot_val for autovacuum_vacuum_score_weight as proof of the effective value on an initialized or managed cluster.
• Applying a change as though it were immediate while pg_settings reports sighup context.
• Changing this setting in isolation without checking the linked limits, observability, and rollback path.
• Depending on beta behavior in production without retesting the PostgreSQL 19 final release.

Related parameters

autovacuum_freeze_score_weight · autovacuum_multixact_freeze_score_weight · autovacuum_vacuum_insert_score_weight · autovacuum_analyze_score_weight · autovacuum_max_workers · autovacuum_naptime

References

• PostgreSQL 19 Beta 3 — autovacuum_vacuum_score_weight
• PostgreSQL 19 release notes
• Machine-readable GUC export

20 - autovacuum_vacuum_threshold

Identity

Lifecycle

Default history

How it works

Minimum number of tuple updates or deletes prior to vacuum. A configuration reload applies a new value; existing work already in flight is not retroactively changed.

The ordinary automatic-vacuum threshold is the base term plus scale factor times reltuples, capped by autovacuum_vacuum_max_threshold from PG18. It reacts to dead tuples from updates/deletes, permits per-table overrides, and is separate from mandatory anti-wraparound vacuuming.

Monitor and change autovacuum_vacuum_threshold together with autovacuum_vacuum_scale_factor, autovacuum_vacuum_max_threshold, autovacuum_vacuum_insert_threshold. Validate on the relevant server role and real workload, then use its sighup context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Changing the global value while a table storage parameter overrides it.
• Treating reltuples and cumulative change statistics as exact real-time counts.
• Blaming a threshold without checking long transactions, replication slots, and worker saturation.
• Buying short-term quiet by deferring maintenance until wraparound failsafe activates.

Related parameters

autovacuum_vacuum_scale_factor · autovacuum_vacuum_max_threshold · autovacuum_vacuum_insert_threshold · autovacuum_vacuum_insert_scale_factor · autovacuum · autovacuum_analyze_scale_factor

References

• PostgreSQL 19 Beta 3 — autovacuum_vacuum_threshold
• PostgreSQL 19 release notes
• Machine-readable GUC export

21 - autovacuum_worker_slots

Identity

Lifecycle

Default history

How it works

Sets the number of backend slots to allocate for autovacuum workers. The value is fixed when the server starts, so changing it requires a restart.

PG18 separates the startup allocation of backend slots for autovacuum workers from the active concurrency limit autovacuum_max_workers. The slots are reserved at startup so the worker limit can be reloaded within that allocation.

Monitor and change autovacuum_worker_slots together with autovacuum, autovacuum_naptime, autovacuum_max_workers. Validate on the relevant server role and real workload, then use its postmaster context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Changing the global value while a table storage parameter overrides it.
• Treating reltuples and cumulative change statistics as exact real-time counts.
• Blaming a threshold without checking long transactions, replication slots, and worker saturation.
• Buying short-term quiet by deferring maintenance until wraparound failsafe activates.

Related parameters

autovacuum · autovacuum_naptime · autovacuum_max_workers · autovacuum_work_mem · track_counts · autovacuum_analyze_scale_factor

References

• PostgreSQL 19 Beta 3 — autovacuum_worker_slots
• PostgreSQL 19 release notes
• Machine-readable GUC export

22 - vacuum_cost_delay

Identity

Lifecycle

Default history

How it works

Vacuum cost delay in milliseconds. It can be changed at session scope, so different sessions may observe different behavior.

VACUUM accumulates virtual cost for page hits, misses, and dirties; after the balance reaches vacuum_cost_limit it sleeps for vacuum_cost_delay and resets. This is coarse I/O pacing rather than an exact bandwidth cap, and the wraparound failsafe bypasses throttling.

Monitor and change vacuum_cost_delay together with vacuum_cost_limit, vacuum_cost_page_hit, vacuum_cost_page_miss. Validate on the relevant server role and real workload, then use its user context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Changing the global value while a table storage parameter overrides it.
• Treating reltuples and cumulative change statistics as exact real-time counts.
• Blaming a threshold without checking long transactions, replication slots, and worker saturation.
• Buying short-term quiet by deferring maintenance until wraparound failsafe activates.

Related parameters

vacuum_cost_limit · vacuum_cost_page_hit · vacuum_cost_page_miss · vacuum_cost_page_dirty · autovacuum_vacuum_cost_delay · autovacuum_vacuum_cost_limit

References

• PostgreSQL 19 Beta 3 — vacuum_cost_delay
• PostgreSQL 19 release notes
• Machine-readable GUC export

23 - vacuum_cost_limit

Identity

Lifecycle

Default history

How it works

Vacuum cost amount available before napping. It can be changed at session scope, so different sessions may observe different behavior.

VACUUM accumulates virtual cost for page hits, misses, and dirties; after the balance reaches vacuum_cost_limit it sleeps for vacuum_cost_delay and resets. This is coarse I/O pacing rather than an exact bandwidth cap, and the wraparound failsafe bypasses throttling.

Monitor and change vacuum_cost_limit together with vacuum_cost_delay, vacuum_cost_page_hit, vacuum_cost_page_miss. Validate on the relevant server role and real workload, then use its user context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Changing the global value while a table storage parameter overrides it.
• Treating reltuples and cumulative change statistics as exact real-time counts.
• Blaming a threshold without checking long transactions, replication slots, and worker saturation.
• Buying short-term quiet by deferring maintenance until wraparound failsafe activates.

Related parameters

vacuum_cost_delay · vacuum_cost_page_hit · vacuum_cost_page_miss · vacuum_cost_page_dirty · autovacuum_vacuum_cost_delay · autovacuum_vacuum_cost_limit

References

• PostgreSQL 19 Beta 3 — vacuum_cost_limit
• PostgreSQL 19 release notes
• Machine-readable GUC export

24 - vacuum_cost_page_dirty

Identity

Lifecycle

Default history

How it works

Vacuum cost for a page dirtied by vacuum. It can be changed at session scope, so different sessions may observe different behavior.

VACUUM accumulates virtual cost for page hits, misses, and dirties; after the balance reaches vacuum_cost_limit it sleeps for vacuum_cost_delay and resets. This is coarse I/O pacing rather than an exact bandwidth cap, and the wraparound failsafe bypasses throttling.

Monitor and change vacuum_cost_page_dirty together with vacuum_cost_delay, vacuum_cost_limit, vacuum_cost_page_hit. Validate on the relevant server role and real workload, then use its user context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Changing the global value while a table storage parameter overrides it.
• Treating reltuples and cumulative change statistics as exact real-time counts.
• Blaming a threshold without checking long transactions, replication slots, and worker saturation.
• Buying short-term quiet by deferring maintenance until wraparound failsafe activates.

Related parameters

vacuum_cost_delay · vacuum_cost_limit · vacuum_cost_page_hit · vacuum_cost_page_miss · autovacuum_vacuum_cost_delay · autovacuum_vacuum_cost_limit

References

• PostgreSQL 19 Beta 3 — vacuum_cost_page_dirty
• PostgreSQL 19 release notes
• Machine-readable GUC export

25 - vacuum_cost_page_hit

Identity

Lifecycle

Default history

How it works

Vacuum cost for a page found in the buffer cache. It can be changed at session scope, so different sessions may observe different behavior.

VACUUM accumulates virtual cost for page hits, misses, and dirties; after the balance reaches vacuum_cost_limit it sleeps for vacuum_cost_delay and resets. This is coarse I/O pacing rather than an exact bandwidth cap, and the wraparound failsafe bypasses throttling.

Monitor and change vacuum_cost_page_hit together with vacuum_cost_delay, vacuum_cost_limit, vacuum_cost_page_miss. Validate on the relevant server role and real workload, then use its user context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Changing the global value while a table storage parameter overrides it.
• Treating reltuples and cumulative change statistics as exact real-time counts.
• Blaming a threshold without checking long transactions, replication slots, and worker saturation.
• Buying short-term quiet by deferring maintenance until wraparound failsafe activates.

Related parameters

vacuum_cost_delay · vacuum_cost_limit · vacuum_cost_page_miss · vacuum_cost_page_dirty · autovacuum_vacuum_cost_delay · autovacuum_vacuum_cost_limit

References

• PostgreSQL 19 Beta 3 — vacuum_cost_page_hit
• PostgreSQL 19 release notes
• Machine-readable GUC export

26 - vacuum_cost_page_miss

Identity

Lifecycle

Default history

How it works

Vacuum cost for a page not found in the buffer cache. It can be changed at session scope, so different sessions may observe different behavior.

VACUUM accumulates virtual cost for page hits, misses, and dirties; after the balance reaches vacuum_cost_limit it sleeps for vacuum_cost_delay and resets. This is coarse I/O pacing rather than an exact bandwidth cap, and the wraparound failsafe bypasses throttling.

Monitor and change vacuum_cost_page_miss together with vacuum_cost_delay, vacuum_cost_limit, vacuum_cost_page_hit. Validate on the relevant server role and real workload, then use its user context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Changing the global value while a table storage parameter overrides it.
• Treating reltuples and cumulative change statistics as exact real-time counts.
• Blaming a threshold without checking long transactions, replication slots, and worker saturation.
• Buying short-term quiet by deferring maintenance until wraparound failsafe activates.

Related parameters

vacuum_cost_delay · vacuum_cost_limit · vacuum_cost_page_hit · vacuum_cost_page_dirty · autovacuum_vacuum_cost_delay · autovacuum_vacuum_cost_limit

References

• PostgreSQL 19 Beta 3 — vacuum_cost_page_miss
• PostgreSQL 19 release notes
• Machine-readable GUC export

27 - vacuum_failsafe_age

Identity

Lifecycle

Default history

How it works

Age at which VACUUM should trigger failsafe to avoid a wraparound outage. It can be changed at session scope, so different sessions may observe different behavior.

At the failsafe age, a running VACUUM prioritizes advancing the freeze horizon quickly: cost delays stop and optional work such as index cleanup and tail truncation is skipped. This is a last defense against wraparound outage, not a routine performance mode.

Monitor and change vacuum_failsafe_age together with autovacuum_freeze_max_age, vacuum_freeze_min_age, vacuum_freeze_table_age. Validate on the relevant server role and real workload, then use its user context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Treating failsafe as a normal high-throughput VACUUM mode.
• Ignoring skipped index cleanup after the emergency has passed.
• Raising the age to suppress evidence of a maintenance failure.
• Changing the global value while a table storage parameter overrides it.
• Treating reltuples and cumulative change statistics as exact real-time counts.

Related parameters

autovacuum_freeze_max_age · vacuum_freeze_min_age · vacuum_freeze_table_age · autovacuum_multixact_freeze_max_age · vacuum_multixact_freeze_min_age · vacuum_multixact_freeze_table_age

References

• PostgreSQL 19 Beta 3 — vacuum_failsafe_age
• PostgreSQL 19 release notes
• Machine-readable GUC export

28 - vacuum_freeze_min_age

Identity

Lifecycle

Default history

How it works

Sets the minimum XID age at which VACUUM freezes tuple xmin values. It is a user-context setting, so a session can override it for manual VACUUM.

VACUUM computes an XID freeze cutoff from this age. Lower values freeze XIDs earlier and can repeat work on rows soon updated; higher values defer work. The effective value is capped at half of autovacuum_freeze_max_age.

Track age(relfrozenxid) for tables and age(datfrozenxid) for every database. Interpret this lower cutoff with vacuum_freeze_table_age, autovacuum_freeze_max_age, and vacuum_failsafe_age; the separate vacuum_multixact_freeze_min_age controls MXIDs.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Describing the cutoff as an MXID control; MultiXacts use vacuum_multixact_freeze_min_age.
• Converting XID age to time without the measured transaction rate.
• Raising the value so far that routine vacuum loses useful headroom before anti-wraparound work.
• Ignoring per-table autovacuum_freeze_min_age overrides.

Related parameters

autovacuum_freeze_max_age · vacuum_freeze_table_age · vacuum_failsafe_age · vacuum_multixact_freeze_min_age · autovacuum · log_autovacuum_min_duration

References

• PostgreSQL 19 Beta 3 — vacuum_freeze_min_age
• PostgreSQL 19 release notes
• Machine-readable GUC export

29 - vacuum_freeze_table_age

Identity

Lifecycle

Default history

How it works

Sets the XID age at which VACUUM switches to an aggressive scan so it can advance a table’s relfrozenxid. It is a user-context setting.

An aggressive XID scan visits every page not already all-frozen and freezes eligible XIDs. PostgreSQL caps the effective value at 95% of autovacuum_freeze_max_age, leaving room for manual maintenance before forced anti-wraparound autovacuum.

Monitor age(relfrozenxid) and age(datfrozenxid), not relminmxid. The separate vacuum_multixact_freeze_table_age controls MXID-driven aggressive scans.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Monitoring relminmxid instead of the XID horizon relfrozenxid.
• Setting a value above 95% of autovacuum_freeze_max_age and assuming PostgreSQL will use it unchanged.
• Forcing aggressive scans too frequently on large mutable tables.
• Waiting for forced anti-wraparound autovacuum instead of measuring routine full-scan completion time.

Related parameters

autovacuum_freeze_max_age · vacuum_freeze_min_age · vacuum_failsafe_age · vacuum_multixact_freeze_table_age · autovacuum · log_autovacuum_min_duration

References

• PostgreSQL 19 Beta 3 — vacuum_freeze_table_age
• PostgreSQL 19 release notes
• Machine-readable GUC export

30 - vacuum_max_eager_freeze_failure_rate

Identity

Lifecycle

Default history

How it works

Fraction of pages in a relation vacuum can scan and fail to freeze before disabling eager scanning. It can be changed at session scope, so different sessions may observe different behavior.

PG18 ordinary VACUUM may eagerly scan all-visible pages that are not all-frozen; it stops that extra work when the fraction scanned without successful freezing grows too high. Raising the rate can shrink later aggressive scans at the cost of more current I/O.

Monitor and change vacuum_max_eager_freeze_failure_rate together with vacuum_truncate, vacuum_freeze_table_age, autovacuum_freeze_max_age. Validate on the relevant server role and real workload, then use its user context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Treating the value as a percentage integer instead of a fraction between zero and one.
• Raising it and increasing scans of all-visible pages without measuring added I/O and WAL.
• Assuming eager freezing eliminates the need for periodic aggressive VACUUM.
• Ignoring a table-level storage-parameter override.
• Judging success only by pages scanned instead of pages actually frozen and future aggressive-scan work.

Related parameters

vacuum_truncate · vacuum_freeze_table_age · autovacuum_freeze_max_age · maintenance_work_mem · vacuum_failsafe_age · vacuum_freeze_min_age

References

• PostgreSQL 19 Beta 3 — vacuum_max_eager_freeze_failure_rate
• PostgreSQL 19 release notes
• Machine-readable GUC export

31 - vacuum_multixact_failsafe_age

Identity

Lifecycle

Default history

How it works

Multixact age at which VACUUM should trigger failsafe to avoid a wraparound outage. It can be changed at session scope, so different sessions may observe different behavior.

At the failsafe age, a running VACUUM prioritizes advancing the freeze horizon quickly: cost delays stop and optional work such as index cleanup and tail truncation is skipped. This is a last defense against wraparound outage, not a routine performance mode.

Monitor and change vacuum_multixact_failsafe_age together with autovacuum_freeze_max_age, vacuum_freeze_min_age, vacuum_freeze_table_age. Validate on the relevant server role and real workload, then use its user context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Treating failsafe as routine instead of an emergency.
• Monitoring only XID age and missing MXID exhaustion.
• Ignoring post-failsafe index cleanup debt.
• Changing the global value while a table storage parameter overrides it.
• Treating reltuples and cumulative change statistics as exact real-time counts.

Related parameters

autovacuum_freeze_max_age · vacuum_freeze_min_age · vacuum_freeze_table_age · vacuum_failsafe_age · autovacuum_multixact_freeze_max_age · vacuum_multixact_freeze_min_age

References

• PostgreSQL 19 Beta 3 — vacuum_multixact_failsafe_age
• PostgreSQL 19 release notes
• Machine-readable GUC export

32 - vacuum_multixact_freeze_min_age

Identity

Lifecycle

Default history

How it works

Sets the minimum MultiXact age at which VACUUM replaces old tuple xmax MultiXact IDs. It is a user-context setting and is distinct from the XID cutoff.

Lower values make VACUUM process MXIDs earlier; higher values defer that work. PostgreSQL may still remove MultiXacts proactively, and the effective cutoff is capped at half of autovacuum_multixact_freeze_max_age.

Track mxid_age(relminmxid), mxid_age(datminmxid), and pg_multixact member storage. Interpret it with vacuum_multixact_freeze_table_age, autovacuum_multixact_freeze_max_age, and vacuum_multixact_failsafe_age.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Describing the cutoff as an XID control or monitoring only relfrozenxid.
• Ignoring pg_multixact member-space pressure, which can force aggressive work before the configured age.
• Raising the value while long-lived shared row locks continue to generate old MXIDs.
• Using autovacuum_freeze_max_age instead of the MultiXact-specific maximum when calculating the cap.

Related parameters

autovacuum_multixact_freeze_max_age · vacuum_multixact_freeze_table_age · vacuum_multixact_failsafe_age · vacuum_freeze_min_age · autovacuum · log_autovacuum_min_duration

References

• PostgreSQL 19 Beta 3 — vacuum_multixact_freeze_min_age
• PostgreSQL 19 release notes
• Machine-readable GUC export

33 - vacuum_multixact_freeze_table_age

Identity

Lifecycle

Default history

How it works

Sets the MultiXact age at which VACUUM switches to an aggressive scan so it can advance a table’s relminmxid. It is a user-context setting.

An aggressive MXID scan visits every page not already all-frozen and processes eligible MultiXacts. PostgreSQL caps the effective value at 95% of autovacuum_multixact_freeze_max_age.

Monitor mxid_age(relminmxid), mxid_age(datminmxid), and pg_multixact storage. The XID horizon relfrozenxid is controlled by vacuum_freeze_table_age instead.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Monitoring relfrozenxid instead of the MultiXact horizon relminmxid.
• Using autovacuum_freeze_max_age rather than autovacuum_multixact_freeze_max_age for the 95% cap.
• Copying an XID-age policy into an MXID workload with a very different consumption rate.
• Ignoring pg_multixact member-space pressure while age still appears comfortable.

Related parameters

autovacuum_multixact_freeze_max_age · vacuum_multixact_freeze_min_age · vacuum_multixact_failsafe_age · vacuum_freeze_table_age · autovacuum · log_autovacuum_min_duration

References

• PostgreSQL 19 Beta 3 — vacuum_multixact_freeze_table_age
• PostgreSQL 19 release notes
• Machine-readable GUC export

34 - vacuum_truncate

Identity

Lifecycle

Default history

How it works

Enables vacuum to truncate empty pages at the end of the table. It can be changed at session scope, so different sessions may observe different behavior.

At the end of VACUUM, PostgreSQL may take an ACCESS EXCLUSIVE lock and remove wholly empty pages from the physical tail of a table. Disabling truncation avoids that lock episode but leaves the file allocated for later reuse.

Monitor and change vacuum_truncate together with vacuum_max_eager_freeze_failure_rate, vacuum_freeze_table_age, autovacuum_freeze_max_age. Validate on the relevant server role and real workload, then use its user context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Assuming truncation removes empty pages in the middle of a relation; only a contiguous empty tail can be removed.
• Ignoring the ACCESS EXCLUSIVE lock attempt and blocking latency on a busy table.
• Disabling truncation and expecting the operating system file size to shrink anyway.
• Forgetting a table-level vacuum_truncate storage parameter can override the session/global value.
• Relying on truncation during wraparound failsafe, when VACUUM can skip it to finish sooner.

Related parameters

vacuum_max_eager_freeze_failure_rate · vacuum_freeze_table_age · autovacuum_freeze_max_age · maintenance_work_mem · autovacuum · autovacuum_analyze_scale_factor

References

• PostgreSQL 19 Beta 3 — vacuum_truncate
• PostgreSQL 19 release notes
• Machine-readable GUC export