{"Entry":{"collection":"guc","key":"wal_sender_delay","name":"wal_sender_delay","aliases":[],"metadata":{"baseline":false,"boot_human":"1 s","boot_val":"1000","category":"Replication / Master Server","category_zh":"","changed_in":["9.1"],"changes":[{"documentation_changed":false,"fields":{},"from":"8.4","status":"added","to":"9.0"},{"documentation_changed":true,"fields":{"boot_val":{"from":"200","to":"1000"},"category":{"from":"Write-Ahead Log / Streaming Replication","to":"Replication / Master Server"}},"from":"9.0","status":"changed","to":"9.1"},{"documentation_changed":false,"fields":{},"from":"9.1","status":"removed","to":"9.2"}],"content_hash":"a6475ee4795f75f3629942130f495cab914fd8ca124b0f73579883c55cb22be0","context":"sighup","default_changed_in":["9.1"],"default_history":[{"from":"9.0","to":"9.0","value":"200 ms"},{"from":"9.1","to":"9.1","value":"1 s"}],"editorial":{"advice":{"olap":"For an upgrade or analytical estate, inventory every generated configuration before cutover. Map the old control to its successor and compare plans, throughput, WAL, or logging behavior rather than assuming the old numeric value is portable.","oltp":"Do not add this retired name to a current OLTP configuration. Translate its intent to the documented successor, test the migration under connection and write concurrency, and remove stale automation that still emits it.","small":"Delete the obsolete override after recording why it existed. On a small node, prefer the successor's default until measurements justify a new value; an unknown startup parameter can otherwise stop the server."},"mechanism":["PostgreSQL describes wal_sender_delay as follows: “WAL sender sleep time between WAL replications.” A configuration reload applies the value to the server without a full restart. The atlas measures it in PG9.0–9.1; boot_val is the compiled or initialized baseline, not proof of a running cluster's effective setting.","Early WAL senders slept for this interval between attempts to ship more WAL. It disappeared after PostgreSQL 9.1 as sender wakeup and streaming behavior evolved; modern latency and liveness controls are wal_sender_timeout, wal_receiver_status_interval, and wal_receiver_timeout, not a polling delay.","Read it together with wal_sender_timeout, wal_receiver_status_interval, wal_receiver_timeout, max_wal_senders. Check SHOW and pg_settings on the target server, verify the source and pending_restart fields, and compare workload, logs, and resource metrics before and after any change."],"pitfalls":["Treating the measured boot_val for wal_sender_delay as proof of the effective value on an initialized or managed cluster.","Applying a change as though it were immediate while pg_settings reports sighup context.","Changing this setting in isolation without checking the linked limits, observability, and rollback path.","Copying the removed name into a modern postgresql.conf instead of migrating to its documented successor."],"references":[{"title":"PostgreSQL 9.0: wal_sender_delay","url":"https://www.postgresql.org/docs/9.0/runtime-config-wal.html#GUC-WAL-SENDER-DELAY"}],"related":["wal_sender_timeout","wal_receiver_status_interval","wal_receiver_timeout","max_wal_senders"],"summary":"wal_sender_delay — WAL sender sleep time between WAL replications. Observed in PG9.0–9.1; its last measured boot default is 1 s in PG9.1, with sighup context. It was removed in PG9.2."},"enumvals":[],"first_version":"9.0","group":"Replication","group_slug":"replication","imported_at":"2026-09-27T17:57:32.365654+08:00","intro_commit":{},"key":"wal_sender_delay","last_version":"9.1","max_val":"10000","min_val":"1","name":"wal_sender_delay","position":479,"present_in":["9.0","9.1"],"short_desc":"Specifies the delay between activity rounds for WAL sender processes.","short_desc_zh":"","source_rev":"english-manuals:2958f3b03895eddbb94a9f0584a6a2dd5044701b61e1979a89aa481d2538006f","unit":"ms","vartype":"integer"}},"Definition":{"Collection":"guc","Key":"wal_sender_delay","SourceDatabase":"center","Version":"9.1","SourceTable":"guc","SourceKey":"wal_sender_delay","SourceRevision":"english-manuals:2958f3b03895eddbb94a9f0584a6a2dd5044701b61e1979a89aa481d2538006f","Facts":{"boot_val":"1000","category":"Replication / Master Server","context":"sighup","description":"Specifies the delay between activity rounds for WAL sender processes. In each round the WAL sender sends any WAL accumulated since the last round to the standby server. It then sleeps for wal_sender_delay milliseconds, and repeats. The sleep is interrupted by transaction commit, so the effects of a committed transaction are sent to standby servers as soon as the commit happens, regardless of this setting. The default value is one second (1s). Note that on many systems, the effective resolution of sleep delays is 10 milliseconds; setting wal_sender_delay to a value that is not a multiple of 10 might have the same results as setting it to the next higher multiple of 10. This parameter can only be set in the postgresql.conf file or on the server command line.","doc":{"anchor":"GUC-WAL-SENDER-DELAY","file":"runtime-config-replication.html","lang":"en","sha256":"4fe02df56a7f0fbd2074c65dfeec10fd78864514cb3093fd697f695b5f5847de","slug":"9.1"},"documented":true,"enumvals":null,"extra_desc":null,"lang":"en","max_val":"10000","metadata_version":"9.1","min_val":"1","name":"wal_sender_delay","short_desc":"WAL sender sleep time between WAL replications.","source":"pg-settings-source-snapshot","unit":"ms","vartype":"integer"},"ManualEvidence":{"doc":{"anchor":"GUC-WAL-SENDER-DELAY","file":"runtime-config-replication.html","lang":"en","sha256":"4fe02df56a7f0fbd2074c65dfeec10fd78864514cb3093fd697f695b5f5847de","slug":"9.1"}},"MeasuredEvidence":{"metadata_version":"9.1"}},"Text":{"Collection":"guc","Key":"wal_sender_delay","SourceDatabase":"pgweb","Version":"9.1","Locale":"zh-Hans","Title":"wal_sender_delay","Summary":"","BodyHTML":"\u003cp\u003e指定 WAL 发送进程各轮活动之间的延迟。在每一轮中，WAL 发送进程会把自上一轮以来累积的所有 WAL 发送给备库，然后休眠\u003ccode\u003ewal_sender_delay\u003c/code\u003e毫秒，再重复此过程。休眠会被事务提交打断，因此已提交事务的效果会在提交发生时立即发送给备库，不受此设置的影响。默认值为一秒（\u003ccode\u003e1s\u003c/code\u003e）。注意，在许多系统上，休眠延迟的有效分辨率为 10 毫秒；将\u003ccode\u003ewal_sender_delay\u003c/code\u003e设为不是 10 的倍数的值，可能与将它设为下一个更大的 10 的倍数效果相同。这个参数只能在\u003ccode\u003epostgresql.conf\u003c/code\u003e文件中或在服务器命令行上设置。\u003c/p\u003e","SourceRevision":"2026-09-11@29c86d9","ContentHash":"98ff62453a167f3c58e0c29632df316f51ad4cf6988f530bdfe55a0fce3f1625","Payload":{"carried_from":"","carry_reason":"","doc_html":"\u003cp\u003e指定 WAL 发送进程各轮活动之间的延迟。在每一轮中，WAL 发送进程会把自上一轮以来累积的所有 WAL 发送给备库，然后休眠\u003ccode class=\"varname\"\u003ewal_sender_delay\u003c/code\u003e毫秒，再重复此过程。休眠会被事务提交打断，因此已提交事务的效果会在提交发生时立即发送给备库，不受此设置的影响。默认值为一秒（\u003ccode class=\"literal\"\u003e1s\u003c/code\u003e）。注意，在许多系统上，休眠延迟的有效分辨率为 10 毫秒；将\u003ccode class=\"varname\"\u003ewal_sender_delay\u003c/code\u003e设为不是 10 的倍数的值，可能与将它设为下一个更大的 10 的倍数效果相同。这个参数只能在\u003ccode class=\"filename\"\u003epostgresql.conf\u003c/code\u003e文件中或在服务器命令行上设置。\u003c/p\u003e","doc_same_as":""}},"RequestedLocale":"zh-Hans","Fallback":false,"Versions":["9.0","9.1"],"Locales":["en","zh-Hans"],"Signatures":null,"Spellings":null,"SQLState":null,"Evidence":null}