Skip to content

Timeout: RegisterSyncRequest

Waiting while sending synchronization requests to the checkpointer, because the request queue is full
PostgreSQL wait event dossier
ClassTimeout EventRegisterSyncRequest VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting while sending synchronization requests to the checkpointer, because the request queue is full

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18

Trigger mechanism

WAIT_EVENT_REGISTER_SYNC_REQUEST at src/backend/storage/sync/sync.c:615 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:180. The instrumented operation is: Waiting while sending synchronization requests to the checkpointer, because the request queue is full. The RegisterSyncRequest 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

Sessions waiting on Timeout/RegisterSyncRequest
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 = 'RegisterSyncRequest'
ORDER BY query_age DESC NULLS LAST;
Current Timeout cohort
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;
Lock and relation context for these sessions
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 = 'RegisterSyncRequest'
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