wal_sender_delay

手册说明

本站手册未收录此参数的说明。

机制详解

wal_sender_delay：设置 WAL sender 两次复制动作之间的休眠时间。重新加载配置即可让服务器采用新值，无需完整重启。 本站在 PG9.0–9.1 实测到它；boot_val 是编译或初始化基线，并不能证明某个运行集群的当前有效值。

早期 WAL sender 每次尝试发送更多 WAL 之间按该值休眠。随着 sender 唤醒与流式行为演进，它在 PG9.1 后退出；现代延迟与存活控制使用 wal_sender_timeout、wal_receiver_status_interval 和 wal_receiver_timeout，而不是轮询延迟。

应与 wal_sender_timeout、wal_receiver_status_interval、wal_receiver_timeout、max_wal_senders 一起理解。请在目标服务器检查 SHOW 与 pg_settings，确认 source 和 pending_restart，并在修改前后对比真实负载、日志和资源指标。

调优建议

按典型负载给出的取值思路，不是放之四海皆准的配方：实际取值要看数据量、并发度与硬件。

• OLTP在线事务处理

  不要把这个已退出的名称加入现代 OLTP 配置。应把原意迁移到文档给出的后继参数，在连接与写并发下验证，并清理仍会输出旧名称的自动化。

• OLAP分析与批处理

  升级分析型环境前应盘点所有生成配置，把旧控制映射到后继项，并比较执行计划、吞吐、WAL 或日志行为；不能假设旧数值可直接搬用。

• 小规格低配实例与开发机

  记录旧覆盖存在的原因后将其删除。小节点应先采用后继参数默认值，实测后再调整；未知的启动参数可能直接阻止服务器启动。

常见问题

• 把 wal_sender_delay 的实测 boot_val 当成初始化后或托管集群当前有效值的证明。
• 忽略 pg_settings 报告的 sighup context，误以为修改会立即生效。
• 孤立修改该参数，没有检查关联上限、可观测性和回滚路径。
• 把已移除名称复制到现代 postgresql.conf，而没有迁移到文档给出的后继参数。

演化历史

相邻两个大版本之间的差异，新的在前。版本号链到该版的快照。

1. PostgreSQL 9.2 ← 9.1 移除此参数

   −该版起不再存在

2. PostgreSQL 9.1 ← 9.0 默认值变更

   默认值 200 ms → 1 s 分类 Write-Ahead Log / Streaming Replication → Replication / Master Server

逐版本快照

每个收录版本里的 7 项事实，与上一个存在的版本不同的格子带底色。版本号链到该版。

关联参数

wal_sender_timeoutwal_receiver_status_intervalwal_receiver_timeoutmax_wal_senders

参考资料

• PostgreSQL 9.0：wal_sender_delay

同类参数