WeSearch

Christophe Pettus: All Your GUCs in a Row: archive_mode

·2 min read · 0 reactions · 0 comments · 0 views
Christophe Pettus: All Your GUCs in a Row: archive_mode

archive_mode is the master switch for WAL archiving. With the last three posts under our belts — archive_cleanup_command, archive_command, archive_library…

Original article
Postgr
Read full at Postgr →
Full article excerpt tap to expand

27 Apr 2026 2 min read All Your GUCs in a Row: archive_mode archive_mode is the master switch for WAL archiving. With the last three posts under our belts — archive_cleanup_command, archive_command, archive_library — we now get to the parameter that decides whether any of that machinery runs at all. Three values: off (default), on, and always. Context is postmaster, which means flipping it requires a server restart. This is the single most important operational fact about this parameter, and the reason the design separates archive_mode from the command/library settings: you can change archive_command or archive_library at runtime via sighup, but whether archiving happens at all is a restart-level decision. Anyone who has ever needed to enable archiving on a production database at short notice has learned this the hard way. off — no archiving. The archiver process doesn’t run. pg_wal/ files are recycled as soon as the server is done with them. on — archive when running as primary. On a standby, the archiver sits idle; WAL files replayed from the primary are marked archived-already and never hit archive_command. always — archive on standbys too. Every WAL file the standby streams or restores gets submitted to archive_command again. This is for cascading setups, or setups where you want the standby to continue feeding the archive if the primary dies. It also means you get duplicate archiving from multiple sources, which your archive destination has to handle gracefully. Most backup tools have opinions here; consult theirs. A few corollaries: wal_level = minimal is incompatible with archive_mode = on or always. The server will refuse to start. You want replica or logical, which is the default on PG 10+ anyway. The restart gotcha cuts both ways. Turning archiving off to deal with a runaway archive_command failure also requires a restart. You cannot SET archive_mode = off your way out of a disk-full situation. You can point archive_command at /bin/true via sighup — which tells the server every WAL is safely archived and lets it recycle. This is a controlled lie and you should know exactly what you are doing before telling it. Recommendation: Set archive_mode = on at initial cluster setup, even if you don’t have archiving configured yet. Leave archive_command empty until your backup tool is ready. Then enabling archiving is a one-line sighup change instead of a maintenance window. Use always only when your backup tool’s docs say to.

This excerpt is published under fair use for community discussion. Read the full article at Postgr.

Anonymous · no account needed
Share 𝕏 Facebook Reddit LinkedIn Email

Discussion

0 comments

More from Postgr