Parameter · Replication / Standby Servers
wal_retrieve_retry_interval
Sets the time to wait before retrying to retrieve WAL after a failed attempt.
- Default:
5s - Type: integer (ms)
- Range: 1ms … max (2147483647)
- Applies: Reload
In plain words
A standby can get WAL from three places: the archive (restore_command), streaming from the primary, and its own pg_wal. When none of them has the next piece, it waits wal_retrieve_retry_interval before trying again. Lower values notice new WAL sooner; higher values reduce pointless retries.
For DBAs and operators
The startup process cycles through the sources; while streaming works it simply waits for the WAL receiver and this interval is not involved. It matters for:
- archive-only standbys (log shipping), where each retry runs
restore_commandfor a file that may not exist yet; - reconnect attempts after the primary went away;
- logical replication: the launcher waits this long before restarting a failed apply worker.
Default 5 s. If restore_command is expensive (cloud object storage), raise it to avoid hammering the archive; on a log-shipping standby, new WAL can wait up to this interval after it reaches the archive before it is fetched. The startup process shows wait_event = 'RecoveryRetrieveRetryInterval' while waiting.
How to change it
Change in postgresql.conf or ALTER SYSTEM, then run SELECT pg_reload_conf().
See it in context
Startup process WAL receiver Archiving and point-in-time recovery Logical replication workers Streaming replication
Related parameters
restore_command primary_conninfo wal_receiver_timeout archive_timeout