Write-Ahead Log / Archiving

archive_command

• What it does: Specifies the shell command used to archive completed WAL segment files to your backup storage location.
• Why it matters: This is the fundamental command that enables continuous WAL archiving, which is essential for point-in-time recovery (PITR) and building standby servers. The command executes whenever a WAL segment is complete and ready for archiving. A properly configured archive_command ensures that all WAL files are safely stored and available for recovery operations, making it the cornerstone of PostgreSQL's disaster recovery capability.
• Ideal value & Best Practice: Use a reliable command with error handling: 'test ! -f /path/to/archive/%f && cp %p /path/to/archive/%f'. For cloud storage: 'aws s3 cp %p s3://your-bucket/wal/%f'. Always include error checking and ensure the command returns proper exit codes (0 on success, non-zero on failure). Test thoroughly and monitor for failures.

archive_library

• What it does: Specifies a shared library that provides custom WAL archiving functionality as an alternative to the shell-based archive_command.
• Why it matters: This parameter allows for more sophisticated and reliable archiving implementations compared to shell commands. Library-based archiving can provide better performance, built-in retry mechanisms, and tighter integration with specialized storage systems. It's particularly valuable for enterprise environments with complex storage requirements or those needing advanced features like compression, encryption, or direct cloud storage integration.
• Ideal value & Best Practice: Default empty (uses archive_command). Use library-based archiving for production critical systems: 'mylibrary' or '$libdir/mylibrary'. Ensure the library is properly installed and tested. Library-based solutions generally provide better reliability than shell commands for mission-critical environments.

archive_mode

• What it does: Controls whether WAL archiving is enabled for the PostgreSQL instance.
• Why it matters: This master switch determines whether PostgreSQL will attempt to archive WAL files. When enabled, the server will call archive_command or archive_library for each completed WAL segment. Archiving must be enabled to support point-in-time recovery, continuous archiving backups, and for creating standby servers using WAL shipping.
• Ideal value & Best Practice: Default off. Set to on for all production systems requiring disaster recovery capabilities. Enable before taking your first base backup. Once enabled, ensure archive_command or archive_library is properly configured to avoid server hangs when archiving fails.

archive_timeout

• What it does: Sets the maximum time between WAL file switches, forcing a switch to a new WAL segment after the specified interval even if the current segment isn't full.
• Why it matters: This parameter helps control the maximum amount of data that could be lost in a disaster scenario. By forcing regular WAL file switches, it ensures that archived WAL segments are available at predictable intervals. However, setting this too low can create many small WAL files and increase archiving overhead, while setting it too high increases potential data loss.
• Ideal value & Best Practice: Default 0 (disabled). Set to 5min to 60min based on your recovery point objective (RPO). For critical systems: 1min to 5min. For less critical systems: 30min to 60min. Balance between recovery objectives and system overhead.

---

Try pghealth Free Today 🚀

Start your journey toward a healthier PostgreSQL with pghealth.
You can explore all features immediately with a free trial — no installation required.

👉 Start Free Trial