Skip to content

vacuum_multixact_freeze_table_age

vacuum_multixact_freeze_table_age — Multixact age at which VACUUM should scan whole table to freeze tuples. Observed in PG9.3–19 Beta 3; its last measured boot default is 150000000 in PG19 Beta 3, with user context. This is a beta-snapshot fact and can change before PostgreSQL 19 GA.
Note

Fact — official short description: “Multixact age at which VACUUM should scan whole table to freeze tuples.”

Identity

Type , Valueinteger
Upstream pg_settings type
Context , Valueuser
Settable by an ordinary user
Unit , Value
Raw unit
Range , Value02000000000
Raw limits in the last observed version
Enum values , Value
— for non-enum types
Category , ValueVacuuming / Freezing
Upstream classification
Latest boot value , Value150000000
150000000

Lifecycle

Fact Value
First observed PG9.3
Present in PG9.3–19 Beta 3
Removed in No
Introduction commit fb47de2be6e4 — Separate multixact freezing parameters from xid’s
Commit date 2014-02-13
Discussion

Default history

Measured PG9.0–19 Beta 3 boot defaults
Versions Raw boot_val Unit Human value
PG9.3–19 Beta 3 150000000 150000000

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

Tip

Advice. These are workload-specific starting points and must be validated with measurements.

Workload Guidance
OLTP Choose an MXID threshold that leaves enough time to complete aggressive scans before autovacuum_multixact_freeze_max_age. Measure workloads with heavy shared row locking.
OLAP Most read-only analytics consume few MXIDs, but concurrent loaders can differ. Schedule scans from measured mxid_age and member-space growth rather than copying XID settings.
Small nodes Keep the default and monitor relminmxid/datminmxid. A small database can still consume MXIDs rapidly through row-locking patterns.

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.

Template Effective value Versus upstream boot Source expression
OLTP Unmodified
OLAP Unmodified
CRIT Unmodified
TINY Unmodified
Caution

Advice — pending human review. Fact from the current Pigsty template projection: OLTP: PG9.3–19 Beta 3 unmodified; OLAP: PG9.3–19 Beta 3 unmodified; CRIT: PG9.3–19 Beta 3 unmodified; TINY: PG9.3–19 Beta 3 unmodified. No Pigsty-specific rationale is inferred from an absent override.

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.

autovacuum_multixact_freeze_max_age · vacuum_multixact_freeze_min_age · vacuum_multixact_failsafe_age · vacuum_freeze_table_age · autovacuum · log_autovacuum_min_duration

References