Write-Ahead Log / Archive Recovery

archive_cleanup_command

• What it does: Specifies a shell command to execute at every restart point during recovery to clean up unnecessary archived WAL files.
• Why it matters: This parameter is essential for managing disk space on standby servers or during point-in-time recovery operations. It automatically removes archived WAL files that are no longer needed for recovery, preventing unlimited disk space consumption. Proper cleanup ensures that storage doesn't fill up with unnecessary WAL segments while maintaining those required for ongoing replication or future recovery needs.
• Ideal value & Best Practice: Typically set to use the pg_archivecleanup utility: 'pg_archivecleanup /path/to/archive %r'. Ensure the command is tested and properly secured. The command should only remove WAL files that are older than the current recovery point. Always include proper error handling in your cleanup scripts.

recovery_end_command

• What it does: Specifies a shell command to execute once at the conclusion of the recovery process.
• Why it matters: This parameter provides a hook for performing custom actions after successful recovery completion but before the server transitions to normal operation. This is valuable for tasks such as sending notifications, updating status files, triggering failover procedures, or cleaning up temporary resources used during recovery. It helps automate post-recovery operational procedures.
• Ideal value & Best Practice: Use for specific cleanup or notification tasks: '/usr/local/bin/notify-recovery-complete.sh'. Ensure the command is idempotent (safe to run multiple times) and has proper error handling. Test thoroughly as command failures may affect server startup. Keep commands simple and fast to execute.

restore_command

• What it does: Specifies the shell command used to retrieve archived WAL files from storage during recovery operations.
• Why it does: This is the most critical parameter for archive-based recovery and replication. It defines how PostgreSQL accesses your archived WAL segments when performing recovery, point-in-time recovery, or building standby servers. The command must be able to fetch required WAL files from your archive storage location and deliver them to the database server for application.
• Ideal value & Best Practice: Example for local archive: 'cp /path/to/archive/%f %p'. For cloud storage: 'aws s3 cp s3://your-bucket/wal/%f %p'. The command must return exit code 0 on success, non-zero on failure. Include retry logic for unreliable storage. Test thoroughly and monitor for failures during recovery operations.

---

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