{"Entry":{"collection":"guc","key":"max_wal_senders","name":"max_wal_senders","aliases":[],"metadata":{"baseline":false,"boot_human":"Not specified","boot_val":null,"category":"Replication / Sending Servers","category_zh":"","changed_in":["9.1","9.2","9.6","10"],"changes":[{"documentation_changed":false,"fields":{},"from":"8.4","status":"added","to":"9.0"},{"documentation_changed":true,"fields":{"category":{"from":"Write-Ahead Log / Streaming Replication","to":"Replication / Master Server"},"max_val":{"from":"536870911","to":"8388607"}},"from":"9.0","status":"changed","to":"9.1"},{"documentation_changed":false,"fields":{"category":{"from":"Replication / Master Server","to":"Replication / Sending Servers"}},"from":"9.1","status":"changed","to":"9.2"},{"documentation_changed":true,"fields":{},"from":"9.3","status":"changed","to":"9.4"},{"documentation_changed":true,"fields":{"max_val":{"from":"8388607","to":"262143"}},"from":"9.5","status":"changed","to":"9.6"},{"documentation_changed":true,"fields":{"boot_val":{"from":"0","to":"10"}},"from":"9.6","status":"changed","to":"10"},{"documentation_changed":true,"fields":{},"from":"10","status":"changed","to":"11"},{"documentation_changed":true,"fields":{},"from":"11","status":"changed","to":"12"},{"documentation_changed":true,"fields":{},"from":"12","status":"changed","to":"13"},{"documentation_changed":true,"fields":{},"from":"13","status":"changed","to":"14"},{"documentation_changed":true,"fields":{},"from":"19","status":"changed","to":"20"}],"content_hash":"e72e5cf6cdc6746e19adf0fe133ead1d1d09f61e263b1fe4ecc5dc527c8cca9e","context":"","default_changed_in":["10"],"default_history":[{"from":"9.0","to":"9.6","value":"0"},{"from":"10","to":"19","value":"10"}],"editorial":{"advice":{"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."},"mechanism":["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."],"pitfalls":["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."],"references":[{"title":"PostgreSQL 19 Beta 4: max_wal_senders","url":"https://www.postgresql.org/docs/19/runtime-config-replication.html#GUC-MAX-WAL-SENDERS"},{"title":"PostgreSQL 19 release notes","url":"https://www.postgresql.org/docs/19/release-19.html"}],"related":["wal_level","max_replication_slots","archive_mode","wal_log_hints","output_plugin_libraries","wal_sender_timeout"],"summary":"max_wal_senders — Sets the maximum number of simultaneously running WAL sender processes. Observed in PG9.0–19 Beta 4; its last measured boot default is 10 in PG19 Beta 4, with postmaster context. This is a beta-snapshot fact and can change before PostgreSQL 19 GA."},"enumvals":[],"first_version":"9.0","group":"Replication","group_slug":"replication","imported_at":"2026-09-27T17:57:31.758842+08:00","intro_commit":{},"key":"max_wal_senders","last_version":"20","max_val":"","min_val":"","name":"max_wal_senders","position":288,"present_in":["9.0","9.1","9.2","9.3","9.4","9.5","9.6","10","11","12","13","14","15","16","17","18","19","20"],"short_desc":"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).","short_desc_zh":"","source_rev":"english-manuals:6a2cd8a8b64a40e16c69cdc15f4dacd39eb5627654217cb10a0b04bb375bb2fd","unit":"","vartype":"integer"}},"Definition":{"Collection":"guc","Key":"max_wal_senders","SourceDatabase":"center","Version":"18","SourceTable":"guc","SourceKey":"max_wal_senders","SourceRevision":"english-manuals:6a2cd8a8b64a40e16c69cdc15f4dacd39eb5627654217cb10a0b04bb375bb2fd","Facts":{"boot_val":"10","category":"Replication / Sending Servers","context":"postmaster","description":"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.","doc":{"anchor":"GUC-MAX-WAL-SENDERS","file":"runtime-config-replication.html","lang":"en","sha256":"c78480a202f8579e2655e080060afe4859c9eb26a16318fb9099dabb178fb32d","slug":"18"},"documented":true,"enumvals":null,"extra_desc":null,"lang":"en","max_val":"262143","metadata_version":"18","min_val":"0","name":"max_wal_senders","short_desc":"Sets the maximum number of simultaneously running WAL sender processes.","source":"pg-settings-source-snapshot","unit":null,"vartype":"integer"},"ManualEvidence":{"doc":{"anchor":"GUC-MAX-WAL-SENDERS","file":"runtime-config-replication.html","lang":"en","sha256":"c78480a202f8579e2655e080060afe4859c9eb26a16318fb9099dabb178fb32d","slug":"18"}},"MeasuredEvidence":{"metadata_version":"18"}},"Text":{"Collection":"guc","Key":"max_wal_senders","SourceDatabase":"center","Version":"18","Locale":"en","Title":"max_wal_senders","Summary":"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.","BodyHTML":"\u003cp\u003eSpecifies 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.\u003c/p\u003e","SourceRevision":"english-manuals:6a2cd8a8b64a40e16c69cdc15f4dacd39eb5627654217cb10a0b04bb375bb2fd","ContentHash":"7ebd3e2d05405c389db2e5d6157b5edff4c2063507fb1948a6fc464b23eec549","Payload":{"description":"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."}},"RequestedLocale":"zh-Hans","Fallback":true,"Versions":["10","11","12","13","14","15","16","17","18","19","20","9.0","9.1","9.2","9.3","9.4","9.5","9.6"],"Locales":["en"],"Signatures":null,"Spellings":null,"SQLState":null,"Evidence":null}