max_wal_senders

Definition PG 18 manual

Specifies the maximum number of concurrent connections from standby servers or streaming base backup clients (i.e., the maximum number of simultaneously running WAL sender processes). The default is 10. The value 0 means replication is disabled. Abrupt disconnection of a streaming client might leave an orphaned connection slot behind until a timeout is reached, so this parameter should be set slightly higher than the maximum number of expected clients so disconnected clients can immediately reconnect. This parameter can only be set at server start. Also, wal_level must be set to replica or higher to allow connections from standby servers.

When running a standby server, you must set this parameter to the same or higher value than on the primary server. Otherwise, queries will not be allowed in the standby server.

How it works

Sets the maximum number of simultaneously running WAL sender processes. The value is fixed when the server starts, so changing it requires a restart.

Each streaming standby, WAL-streaming base backup, or logical replication connection can occupy a WAL sender. Zero disables sending, disconnected clients may retain a slot until timeout, and a standby must reserve at least as many senders as its primary to accept hot-standby queries safely.

Monitor and change max_wal_senders together with wal_level, max_replication_slots, archive_mode. Validate on the relevant server role and real workload, then use its postmaster context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Operational considerations

Changing it on the wrong primary, standby, sender, or subscriber role.

Watching only configured bytes/time instead of actual lag, slot position, and worker state.

Failing over to a node that lacks the old primary's capacity or prerequisites.

Using infinite waits or WAL retention to hide a failed consumer.

Workload guidance

OLAP: Read standbys and logical subscribers often see long queries or large transactions. Put explicit bounds on replay/apply and monitor lag, worker saturation, slot restart_lsn, and conflict cancellations.

OLTP: Size max_wal_senders from topology, failover roles, slot/subscription count, and reconnect headroom. Test worst-case primary latency, standby replay, and disk retention before production.

SMALL: Configure only replication capacity that is actually used. Even a small topology needs bounded timeouts and slot lifecycle; unlimited retention is not reliability.