Timeout: RecoveryRetrieveRetryInterval

Official description

Waiting during recovery when WAL data is not available from any source (pg_wal, archive or stream)

Trigger mechanism

WAIT_EVENT_RECOVERY_RETRIEVE_RETRY_INTERVAL at src/backend/access/transam/xlogrecovery.c:3764 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:179. The instrumented operation is: Waiting during recovery when WAL data is not available from any source (pg_wal, archive or stream). The RecoveryRetrieveRetryInterval path deliberately waits on a timer, retry interval, throttle, or safety backoff. The latch timeout expires before work is reconsidered.

Normal or trouble?

• Normal: The wait is normal when the configured policy is intentional and useful work advances at the expected rate.
• Investigate: Investigate when the policy causes missed maintenance, recovery, backup, or latency objectives, or when a spin delay persists.

Diagnostic SQL

SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'Timeout'
  AND wait_event = 'RecoveryRetrieveRetryInterval'
ORDER BY query_age DESC NULLS LAST;

SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'Timeout'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;

SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'Timeout'
  AND a.wait_event = 'RecoveryRetrieveRetryInterval'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

1. Identify the GUC or function that owns the timer.
2. Compare productive work with time spent delayed.
3. Adjust the policy only after checking the CPU, I/O, and durability pressure it was designed to control.

Source evidence

• PostgreSQL 18.6 · src/backend/access/transam/xlogrecovery.c:3764 — WAIT_EVENT_RECOVERY_RETRIEVE_RETRY_INTERVAL
• PostgreSQL 18.6 · src/backend/utils/activity/wait_event_names.txt:179 — RECOVERY_RETRIEVE_RETRY_INTERVAL

Related controls and signals

• GUCs: None directly.
• Metrics: [metric:waiting_sessions] · [metric:wait_event_share]