archive_mode

archive_mode — Allows archiving of WAL files using “archive_command”. Observed in PG9.0–19 Beta 3; its last measured boot default is off in PG19 Beta 3, with postmaster context. This is a beta-snapshot fact and can change before PostgreSQL 19 GA.

Note

Fact — official short description: “Allows archiving of WAL files using “archive_command”.”

Identity

Type , Valueenum: Upstream pg_settings type
Context , Valuepostmaster: Requires a server restart
Unit , Value—: Raw unit
Range , Value—: Raw limits in the last observed version
Enum values , Valuealways, on, off: — for non-enum types
Category , ValueWrite-Ahead Log / Archiving: Upstream classification
Latest boot value , Valueoff: off

Lifecycle

Fact	Value
First observed	PG9.0 (research boundary)
Present in	PG9.0–19 Beta 3
Removed in	No
Introduction commit	Not asserted: predates the PG9.0 research boundary
Commit date	—
Discussion	—

Default history

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

How it works

When enabled, PostgreSQL runs the WAL archiver and submits each completed segment to archive_command or, in versions that provide it, archive_library before that segment can be recycled. The mode is separate from the command or library, so the archive destination logic can be reloaded while archiving remains enabled.

The on and always modes behave the same during normal primary operation. In recovery or standby mode, on does not archive received WAL, while always also archives segments restored from an archive or received through streaming replication.

Enabling the mode does not prove that an archive is healthy or recoverable. A command that fails causes WAL to accumulate in pg_wal; a command that falsely reports success can create an unrecoverable archive chain. Point-in-time recovery also requires a suitable base backup and tested restore procedure.

Tuning advice

Tip

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

Workload	Guidance
OLTP	Enable it for a defined PITR or log-shipping requirement, pair it with a reliable idempotent archive implementation, and alert on pg_stat_archiver failures, archive age, and pg_wal growth. Test restores rather than treating successful command exits as sufficient evidence.
OLAP	Provision archive bandwidth and destination capacity for bulk-load WAL bursts. If the archive cannot keep up, throttling or scheduling the batch is safer than allowing pg_wal to fill.
Small nodes	Use a simple managed tool such as pgBackRest only when retention and restore procedures are understood. Keep the archive off for disposable databases rather than enabling it with a placeholder command.

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	`on`	different	`'on'`
OLAP	`on`	different	`'on'`
CRIT	`on`	different	`'on'`
TINY	`on`	different	`'on'`

Caution

Advice — pending human review. Fact from the current Pigsty template projection: OLTP: PG9.0–19 Beta 3 = on (dcs); OLAP: PG9.0–19 Beta 3 = on (dcs); CRIT: PG9.0–19 Beta 3 = on (dcs); TINY: PG9.0–19 Beta 3 = on (dcs). Advice, pending human review — confirm the operational intent against the current Pigsty templates and supported PostgreSQL versions before publication.

Common pitfalls

Enabling archive_mode with an empty or failing command and letting pg_wal fill.
Using a command such as /bin/true, which reports success while breaking the recoverable WAL chain.
Assuming archive_mode is reloadable even though changing it requires a server restart.
Treating WAL archiving as a substitute for a base backup and restore test.
Using always with a shared archive without duplicate-safe, race-free handling.

archive_command · archive_library · archive_timeout · wal_level · restore_command · max_wal_size