Parameter · Replication / Sending Servers
wal_sender_timeout
Sets the maximum time to wait for WAL replication.
- Default:
1min - Type: integer (ms)
- Range: 0 … max (2147483647)
- Applies: Session (any user)
In plain words
A standby or subscriber regularly sends status replies to its WAL sender. If the WAL sender hears nothing for wal_sender_timeout, it assumes the other side crashed or the network died, and ends the connection so the slot and process slot are freed.
Default 60 seconds. 0 disables the check.
For DBAs and operators
When half the timeout has passed without a reply, the WAL sender sends a keepalive asking for an immediate reply; only total silence for the full period terminates it:
LOG: terminating walsender process due to replication timeout
The receiving side must reply often enough: physical standbys send status at least every wal_receiver_status_interval. A common cause of this message in tickets is a subscriber whose apply worker is stuck (long lock wait, huge transaction) or a busy network path / NAT dropping idle TCP sessions.
It can be set per connection, because the context is user: e.g. a remote standby with primary_conninfo = '… options=''-c wal_sender_timeout=5min'''. Shorter values detect failures faster (useful with synchronous replication: a dead sync standby blocks commits, and only once its sender gives up can another listed standby take over); longer values tolerate slow links. Pair it with wal_receiver_timeout on the other side.
How to change it
Any user can change it for their session with SET.
See it in context
Related parameters
wal_receiver_timeout wal_receiver_status_interval max_wal_senders tcp_keepalives_idle