Specifies how long the standby server should wait when WAL data is not available from any sources (streaming physical replication, local pg_wal or WAL archive) before trying again to retrieve WAL data.
At a glance
| Property | Value |
|---|---|
| Parameter | wal_retrieve_retry_interval |
| Category | Replication |
| Default | 5 |
| Value type | integer |
| Change scope | Reload (postgresql.conf, SIGHUP) |
| Available in | PostgreSQL 12, 13, 14, 15, 16, 17, 18, 19 (added in 12) |
What it does
Specifies how long the standby server should wait when WAL data is not available from any sources (streaming physical replication, local pg_wal or WAL archive) before trying again to retrieve WAL data. If this value is specified without units, it is taken as milliseconds. The default value is 5 seconds. This parameter can only be set in the postgresql.conf file or on the server command line.
This parameter is useful in configurations where a node in recovery needs to control the amount of time to wait for new WAL data to be available. For example, in archive recovery, it is possible to make the recovery more responsive in the detection of a new WAL file by reducing the value of this parameter. On a system with low WAL activity, increasing it reduces the amount of requests necessary to access WAL archives, something useful for example in cloud environments where the number of times an infrastructure is accessed is taken into account.
(Description quoted from the official PostgreSQL documentation.)
How to apply a change
Set it in postgresql.conf (or with ALTER SYSTEM) and reload with SELECT pg_reload_conf(); or pg_ctl reload — no restart needed.
Inspect the current value and source with SHOW wal_retrieve_retry_interval; or SELECT name, setting, unit, context, source FROM pg_settings WHERE name = 'wal_retrieve_retry_interval';.
Tuning guidance
This parameter is rarely a performance lever. Leave it at the default unless you have a specific, documented reason to change it, change it on one session or one role/database first, and confirm the effect with pg_settings and your own measurements before rolling it out cluster-wide.