这是本节的多页打印视图。 .
复制
- 1: hot_standby
- 2: hot_standby_feedback
- 3: idle_replication_slot_timeout
- 4: max_active_replication_origins
- 5: max_logical_replication_workers
- 6: max_parallel_apply_workers_per_subscription
- 7: max_repack_replication_slots
- 8: max_replication_slots
- 9: max_slot_wal_keep_size
- 10: max_standby_archive_delay
- 11: max_standby_streaming_delay
- 12: max_sync_workers_per_subscription
- 13: max_wal_senders
- 14: output_plugin_libraries
- 15: primary_conninfo
- 16: primary_slot_name
- 17: promote_trigger_file
- 18: recovery_min_apply_delay
- 19: replication_timeout
- 20: sync_replication_slots
- 21: synchronized_standby_slots
- 22: synchronous_standby_names
- 23: track_commit_timestamp
- 24: vacuum_defer_cleanup_age
- 25: wal_keep_segments
- 26: wal_keep_size
- 27: wal_receiver_create_temp_slot
- 28: wal_receiver_status_interval
- 29: wal_receiver_timeout
- 30: wal_retrieve_retry_interval
- 31: wal_sender_delay
- 32: wal_sender_shutdown_timeout
- 33: wal_sender_timeout
条目 URL 保持扁平；本分类仅用于侧栏与浏览组织。
1 - hot_standby
Fact — 官方简述译文：允许在恢复期间连接并执行查询。
身份
类型,- 上游 pg_settings 类型
Context,- 修改后需要重启数据库
单位,- 原始单位
范围,- 最后在档版本的原始上下限
枚举值,- 非枚举类型记为 —
分类,- 上游分类
最后 boot 值,- on
生命周期
| Fact | 值 |
|---|---|
| 首次观测 | PG9.0（研究下界） |
| 在档版本 | PG9.0–19 Beta 3 |
| 移除版本 | 否 |
| 引入提交 | 不作断言：早于 PG9.0 研究边界 |
| 提交日期 | — |
| Discussion | — |
默认值变迁
| 版本 | 原始 boot_val |
单位 | 人类可读值 |
|---|---|---|---|
| PG9.0–9.6 | off |
— | off |
| PG10–19 Beta 3 | on |
— | on |
机制详解
允许在恢复期间连接并执行查询。该值在服务器启动时固定，修改后必须重启。
它只在对应的发送端、主库、备库或订阅端角色上生效；级联复制与故障切换会改变服务器角色，因此相关容量和依赖应在所有候选节点一致规划。
应把 hot_standby 与 primary_conninfo、primary_slot_name、restore_command 一起监控和变更。先在对应角色与真实负载上验证，再按其 postmaster context 选择会话修改、reload 或 restart；历史默认值并不等于当前有效值。
调优建议
Advice。 以下建议是工作负载起点，必须用真实测量验证。
| 场景 | 建议 |
|---|---|
| OLTP | 按主备拓扑、故障切换角色、复制槽/订阅数量与断连余量规划 hot_standby；上线前验证主库写延迟、备库重放和磁盘保留的最坏情况。 |
| OLAP | 读备库与逻辑订阅常有长查询或大事务，应给重放/应用留明确上界，并监控延迟、worker 饱和、槽 restart_lsn 与冲突取消。 |
| 小规格 | 只配置真实需要的复制能力。少量节点也应设置有界超时与槽生命周期，不要用无限保留换取表面稳定。 |
Pigsty 取值
以下值来自固定 8 核、32 GiB、100 GiB SSD 夹具，并按 PG19 Beta 3 渲染当前 Pigsty 模板；这不表示 Pigsty 当前支持该历史或测试版本。
| 模板 | 有效值 | 与上游 boot 比较 | 源表达式 |
|---|---|---|---|
| OLTP | 未修改 | — | — |
| OLAP | 未修改 | — | — |
| CRIT | 未修改 | — | — |
| TINY | 未修改 | — | — |
Advice — 待人工复核。 当前 Pigsty 模板投影事实：OLTP: PG9.0–19 Beta 3 未修改；OLAP: PG9.0–19 Beta 3 未修改；CRIT: PG9.0–19 Beta 3 未修改；TINY: PG9.0–19 Beta 3 未修改。 未发现覆盖值，因此不推断 Pigsty 专属理由。
常见坑
- 在错误的主库、备库、发送端或订阅端角色上修改。
- 只看字节/时间配置，不监控真实复制延迟、槽位置与 worker 状态。
- 故障切换后新主库缺少与旧主库一致的容量或依赖。
- 用无限等待或无限 WAL 保留掩盖失效消费者。
关联参数
primary_conninfo · primary_slot_name · restore_command · wal_receiver_timeout · wal_retrieve_retry_interval · max_standby_archive_delay
参考资料
2 - hot_standby_feedback
Fact — 官方简述译文：允许热备库向主库反馈信息，以避免查询冲突。
身份
类型,- 上游 pg_settings 类型
Context,- 配置 reload 后生效
单位,- 原始单位
范围,- 最后在档版本的原始上下限
枚举值,- 非枚举类型记为 —
分类,- 上游分类
最后 boot 值,- off
生命周期
| Fact | 值 |
|---|---|
| 首次观测 | PG9.1 |
| 在档版本 | PG9.1–19 Beta 3 |
| 移除版本 | 否 |
| 引入提交 | bca8b7f16a3e — Hot Standby feedback for avoidance of cleanup conflicts on standby. Standby optionally sends back information about oldestXmin of queries which is then checked and applied to the WALSender’s proc->xmin. GetOldestXmin() is modified slightly to agree with GetSnapshotData(), so that all backends on primary include WALSender within their snapshots. Note this does nothing to change the snapshot xmin on either master or standby. Feedback piggybacks on the standby reply message. vacuum_defer_cleanup_age is no longer used on standby, though parameter still exists on primary, since some use cases still exist. |
| 提交日期 | 2011-02-16 |
| Discussion | — |
默认值变迁
| 版本 | 原始 boot_val |
单位 | 人类可读值 |
|---|---|---|---|
| PG9.1–19 Beta 3 | off |
— | off |
机制详解
启用后，备库会向主库或上游备库报告当前查询快照仍需要的可见性信息，使上游避免清理由这些查询仍可见的旧行版本。反馈发送频率不会高于 wal_receiver_status_interval。
避免清理冲突会把代价转移到主库：死亡行版本存活更久，表与索引膨胀以及后续 VACUUM 工作都会增加。在级联复制中反馈会继续向上传递，因此很下游的一个旧快照也可能影响主库。
该机制只缓解清理记录冲突，并不能消除全部热备冲突。DDL 锁、删除对象、表空间操作和某些页面级冲突仍会取消查询。无槽备库断开时反馈会中断，时钟跳变也可能影响发送时序。
调优建议
Advice。 以下建议是工作负载起点，必须用真实测量验证。
| 场景 | 建议 |
|---|---|
| OLTP | 只有减少备库查询取消的收益高于主库膨胀风险时才启用。限制备库查询时长，监控事务年龄、死亡元组、表增长、VACUUM 进度和 pg_stat_database_conflicts；纯 HA 备库通常更重视及时重放。 |
| OLAP | 对长查询报表备库很有价值，但必须搭配工作负载超时和主库膨胀预算。如果分析快照经常阻止清理数小时，应考虑独立报表拓扑。 |
| 小规格 | 除非已证明查询取消是问题，否则从 off 开始。有限存储使主库膨胀风险更高；启用后应使用较短查询上限和积极监控。 |
Pigsty 取值
以下值来自固定 8 核、32 GiB、100 GiB SSD 夹具，并按 PG19 Beta 3 渲染当前 Pigsty 模板；这不表示 Pigsty 当前支持该历史或测试版本。
| 模板 | 有效值 | 与上游 boot 比较 | 源表达式 |
|---|---|---|---|
| OLTP | on |
不同于 boot 值 | 'on' |
| OLAP | on |
不同于 boot 值 | 'on' |
| CRIT | on |
不同于 boot 值 | 'on' |
| TINY | on |
不同于 boot 值 | 'on' |
Advice — 待人工复核。 当前 Pigsty 模板投影事实：OLTP: PG9.1–19 Beta 3 = on (dcs)；OLAP: PG9.1–19 Beta 3 = on (dcs)；CRIT: PG9.1–19 Beta 3 = on (dcs)；TINY: PG9.1–19 Beta 3 = on (dcs)。 建议（待人工复核）——发布前应结合当前 Pigsty 模板及其实际支持的 PostgreSQL 版本确认运维意图。
常见坑
- 启用后忽略主库表或索引膨胀。
- 期待它阻止 DDL、锁、删除数据库或表空间冲突。
- 允许下游备库无限长查询长期阻止上游清理。
- 认为无槽备库断开期间反馈仍然有效。
- 分析反馈时序时忽略时钟跳变和 wal_receiver_status_interval。
关联参数
max_standby_streaming_delay · max_standby_archive_delay · wal_receiver_status_interval · primary_slot_name · autovacuum_vacuum_scale_factor · log_recovery_conflict_waits
参考资料
3 - idle_replication_slot_timeout
Fact — 官方简述译文：设置复制槽保持空闲多久后失效。
身份
类型,- 上游 pg_settings 类型
Context,- 配置 reload 后生效
单位,- 原始单位
范围,- 最后在档版本的原始上下限
枚举值,- 非枚举类型记为 —
分类,- 上游分类
最后 boot 值,- 0 s
生命周期
| Fact | 值 |
|---|---|
| 首次观测 | PG18 |
| 在档版本 | PG18–19 Beta 3 |
| 移除版本 | 否 |
| 引入提交 | ac0e33136abc — Invalidate inactive replication slots. |
| 提交日期 | 2025-02-19 |
| Discussion | 讨论 1 · 讨论 2 |
默认值变迁
| 版本 | 原始 boot_val |
单位 | 人类可读值 |
|---|---|---|---|
| PG18–19 Beta 3 | 0 |
s |
0 s |
机制详解
设置复制槽保持空闲多久后失效。重新加载配置即可应用新值；已经开始的工作不会被追溯改变。
PostgreSQL 18 从 pg_replication_slots.inactive_since 计算空闲时间，并在超过阈值后的检查点使合格槽失效。零禁用策略；不保留 WAL 的槽与从主库同步来的备库槽不适用。
应把 idle_replication_slot_timeout 与 max_replication_slots、max_slot_wal_keep_size、primary_slot_name 一起监控和变更。先在对应角色与真实负载上验证，再按其 sighup context 选择会话修改、reload 或 restart；历史默认值并不等于当前有效值。
调优建议
Advice。 以下建议是工作负载起点，必须用真实测量验证。
| 场景 | 建议 |
|---|---|
| OLTP | 按主备拓扑、故障切换角色、复制槽/订阅数量与断连余量规划 idle_replication_slot_timeout；上线前验证主库写延迟、备库重放和磁盘保留的最坏情况。 |
| OLAP | 读备库与逻辑订阅常有长查询或大事务，应给重放/应用留明确上界，并监控延迟、worker 饱和、槽 restart_lsn 与冲突取消。 |
| 小规格 | 只配置真实需要的复制能力。少量节点也应设置有界超时与槽生命周期，不要用无限保留换取表面稳定。 |
Pigsty 取值
以下值来自固定 8 核、32 GiB、100 GiB SSD 夹具，并按 PG19 Beta 3 渲染当前 Pigsty 模板；这不表示 Pigsty 当前支持该历史或测试版本。
| 模板 | 有效值 | 与上游 boot 比较 | 源表达式 |
|---|---|---|---|
| OLTP | 7d |
不同于 boot 值 | 7d |
| OLAP | 7d |
不同于 boot 值 | 7d |
| CRIT | 3d |
不同于 boot 值 | 3d |
| TINY | 7d |
不同于 boot 值 | 7d |
Advice — 待人工复核。 当前 Pigsty 模板投影事实：OLTP: PG18–19 Beta 3 = 7d (dcs)；OLAP: PG18–19 Beta 3 = 7d (dcs)；CRIT: PG18–19 Beta 3 = 3d (dcs)；TINY: PG18–19 Beta 3 = 7d (dcs)。 建议（待人工复核）——编辑推断（待维护者人工复核）：该选择看起来意在使遗忘的 PG18 复制槽失效，并给 CRIT 更严格的窗口；发布前应结合当前 Pigsty 模板、硬件夹具和运维保证复核。
常见坑
- 期待时长一到立刻失效，而不是等后续检查点。
- 误以为同步来的备库槽也适用。
- 自动失效前没有订阅者重建 runbook。
- 在错误的主库、备库、发送端或订阅端角色上修改。
- 只看字节/时间配置，不监控真实复制延迟、槽位置与 worker 状态。
关联参数
max_replication_slots · max_slot_wal_keep_size · primary_slot_name · wal_keep_size · checkpoint_timeout · max_wal_senders
参考资料
4 - max_active_replication_origins
Fact — 官方简述译文：设置可同时活动的复制源最大数量。
身份
类型,- 上游 pg_settings 类型
Context,- 修改后需要重启数据库
单位,- 原始单位
范围,- 最后在档版本的原始上下限
枚举值,- 非枚举类型记为 —
分类,- 上游分类
最后 boot 值,- 10
生命周期
| Fact | 值 |
|---|---|
| 首次观测 | PG18 |
| 在档版本 | PG18–19 Beta 3 |
| 移除版本 | 否 |
| 引入提交 | 04ff636cbce4 — Add GUC option to control maximum active replication origins. |
| 提交日期 | 2025-03-21 |
| Discussion | 讨论 1 |
默认值变迁
| 版本 | 原始 boot_val |
单位 | 人类可读值 |
|---|---|---|---|
| PG18–19 Beta 3 | 10 |
— | 10 |
机制详解
设置可同时活动的复制源最大数量。该值在服务器启动时固定，修改后必须重启。
它只在对应的发送端、主库、备库或订阅端角色上生效；级联复制与故障切换会改变服务器角色，因此相关容量和依赖应在所有候选节点一致规划。
应把 max_active_replication_origins 与 max_logical_replication_workers、max_replication_slots、track_commit_timestamp 一起监控和变更。先在对应角色与真实负载上验证，再按其 postmaster context 选择会话修改、reload 或 restart；历史默认值并不等于当前有效值。
调优建议
Advice。 以下建议是工作负载起点，必须用真实测量验证。
| 场景 | 建议 |
|---|---|
| OLTP | 按主备拓扑、故障切换角色、复制槽/订阅数量与断连余量规划 max_active_replication_origins；上线前验证主库写延迟、备库重放和磁盘保留的最坏情况。 |
| OLAP | 读备库与逻辑订阅常有长查询或大事务，应给重放/应用留明确上界，并监控延迟、worker 饱和、槽 restart_lsn 与冲突取消。 |
| 小规格 | 只配置真实需要的复制能力。少量节点也应设置有界超时与槽生命周期，不要用无限保留换取表面稳定。 |
Pigsty 取值
以下值来自固定 8 核、32 GiB、100 GiB SSD 夹具，并按 PG19 Beta 3 渲染当前 Pigsty 模板；这不表示 Pigsty 当前支持该历史或测试版本。
| 模板 | 有效值 | 与上游 boot 比较 | 源表达式 |
|---|---|---|---|
| OLTP | 未修改 | — | — |
| OLAP | 未修改 | — | — |
| CRIT | 未修改 | — | — |
| TINY | 未修改 | — | — |
Advice — 待人工复核。 当前 Pigsty 模板投影事实：OLTP: PG18–19 Beta 3 未修改；OLAP: PG18–19 Beta 3 未修改；CRIT: PG18–19 Beta 3 未修改；TINY: PG18–19 Beta 3 未修改。 未发现覆盖值，因此不推断 Pigsty 专属理由。
常见坑
- 在错误的主库、备库、发送端或订阅端角色上修改。
- 只看字节/时间配置，不监控真实复制延迟、槽位置与 worker 状态。
- 故障切换后新主库缺少与旧主库一致的容量或依赖。
- 用无限等待或无限 WAL 保留掩盖失效消费者。
关联参数
max_logical_replication_workers · max_replication_slots · track_commit_timestamp · max_parallel_apply_workers_per_subscription · max_sync_workers_per_subscription · hot_standby
参考资料
5 - max_logical_replication_workers
Fact — 官方简述译文：设置逻辑复制 worker 进程的最大数量。
身份
类型,- 上游 pg_settings 类型
Context,- 修改后需要重启数据库
单位,- 原始单位
范围,- 最后在档版本的原始上下限
枚举值,- 非枚举类型记为 —
分类,- 上游分类
最后 boot 值,- 4
生命周期
| Fact | 值 |
|---|---|
| 首次观测 | PG10 |
| 在档版本 | PG10–19 Beta 3 |
| 移除版本 | 否 |
| 引入提交 | 665d1fad99e7 — Logical replication |
| 提交日期 | 2017-01-19 |
| Discussion | — |
默认值变迁
| 版本 | 原始 boot_val |
单位 | 人类可读值 |
|---|---|---|---|
| PG10–19 Beta 3 | 4 |
— | 4 |
机制详解
设置逻辑复制 worker 进程的最大数量。该值在服务器启动时固定，修改后必须重启。
它只在对应的发送端、主库、备库或订阅端角色上生效；级联复制与故障切换会改变服务器角色，因此相关容量和依赖应在所有候选节点一致规划。
应把 max_logical_replication_workers 与 max_parallel_apply_workers_per_subscription、max_sync_workers_per_subscription、max_worker_processes 一起监控和变更。先在对应角色与真实负载上验证，再按其 postmaster context 选择会话修改、reload 或 restart；历史默认值并不等于当前有效值。
调优建议
Advice。 以下建议是工作负载起点，必须用真实测量验证。
| 场景 | 建议 |
|---|---|
| OLTP | 按主备拓扑、故障切换角色、复制槽/订阅数量与断连余量规划 max_logical_replication_workers；上线前验证主库写延迟、备库重放和磁盘保留的最坏情况。 |
| OLAP | 读备库与逻辑订阅常有长查询或大事务，应给重放/应用留明确上界，并监控延迟、worker 饱和、槽 restart_lsn 与冲突取消。 |
| 小规格 | 只配置真实需要的复制能力。少量节点也应设置有界超时与槽生命周期，不要用无限保留换取表面稳定。 |
Pigsty 取值
以下值来自固定 8 核、32 GiB、100 GiB SSD 夹具，并按 PG19 Beta 3 渲染当前 Pigsty 模板；这不表示 Pigsty 当前支持该历史或测试版本。
| 模板 | 有效值 | 与上游 boot 比较 | 源表达式 |
|---|---|---|---|
| OLTP | 8 |
不同于 boot 值 | 8 |
| OLAP | 8 |
不同于 boot 值 | 8 |
| CRIT | 8 |
不同于 boot 值 | 8 |
| TINY | 8 |
不同于 boot 值 | 8 |
Advice — 待人工复核。 当前 Pigsty 模板投影事实：OLTP: PG10–19 Beta 3 = 8 (dcs)；OLAP: PG10–19 Beta 3 = 8 (dcs)；CRIT: PG10–19 Beta 3 = 8 (dcs)；TINY: PG10–19 Beta 3 = 8 (dcs)。 建议（待人工复核）——编辑推断（待维护者人工复核）：该选择看起来意在为多个逻辑订阅与表同步任务留出 worker 余量；发布前应结合当前 Pigsty 模板、硬件夹具和运维保证复核。
常见坑
- 在错误的主库、备库、发送端或订阅端角色上修改。
- 只看字节/时间配置，不监控真实复制延迟、槽位置与 worker 状态。
- 故障切换后新主库缺少与旧主库一致的容量或依赖。
- 用无限等待或无限 WAL 保留掩盖失效消费者。
关联参数
max_parallel_apply_workers_per_subscription · max_sync_workers_per_subscription · max_worker_processes · max_replication_slots · max_active_replication_origins · track_commit_timestamp
参考资料
6 - max_parallel_apply_workers_per_subscription
Fact — 官方简述译文：设置每个订阅的并行应用 worker 最大数量。
身份
类型,- 上游 pg_settings 类型
Context,- 配置 reload 后生效
单位,- 原始单位
范围,- 最后在档版本的原始上下限
枚举值,- 非枚举类型记为 —
分类,- 上游分类
最后 boot 值,- 2
生命周期
| Fact | 值 |
|---|---|
| 首次观测 | PG16 |
| 在档版本 | PG16–19 Beta 3 |
| 移除版本 | 否 |
| 引入提交 | 216a784829c2 — Perform apply of large transactions by parallel workers. |
| 提交日期 | 2023-01-09 |
| Discussion | 讨论 1 |
默认值变迁
| 版本 | 原始 boot_val |
单位 | 人类可读值 |
|---|---|---|---|
| PG16–19 Beta 3 | 2 |
— | 2 |
机制详解
设置每个订阅的并行应用 worker 最大数量。重新加载配置即可应用新值；已经开始的工作不会被追溯改变。
它只在对应的发送端、主库、备库或订阅端角色上生效；级联复制与故障切换会改变服务器角色，因此相关容量和依赖应在所有候选节点一致规划。
应把 max_parallel_apply_workers_per_subscription 与 max_logical_replication_workers、max_sync_workers_per_subscription、max_worker_processes 一起监控和变更。先在对应角色与真实负载上验证，再按其 sighup context 选择会话修改、reload 或 restart；历史默认值并不等于当前有效值。
调优建议
Advice。 以下建议是工作负载起点，必须用真实测量验证。
| 场景 | 建议 |
|---|---|
| OLTP | 按主备拓扑、故障切换角色、复制槽/订阅数量与断连余量规划 max_parallel_apply_workers_per_subscription；上线前验证主库写延迟、备库重放和磁盘保留的最坏情况。 |
| OLAP | 读备库与逻辑订阅常有长查询或大事务，应给重放/应用留明确上界，并监控延迟、worker 饱和、槽 restart_lsn 与冲突取消。 |
| 小规格 | 只配置真实需要的复制能力。少量节点也应设置有界超时与槽生命周期，不要用无限保留换取表面稳定。 |
Pigsty 取值
以下值来自固定 8 核、32 GiB、100 GiB SSD 夹具，并按 PG19 Beta 3 渲染当前 Pigsty 模板；这不表示 Pigsty 当前支持该历史或测试版本。
| 模板 | 有效值 | 与上游 boot 比较 | 源表达式 |
|---|---|---|---|
| OLTP | 未修改 | — | — |
| OLAP | 未修改 | — | — |
| CRIT | 未修改 | — | — |
| TINY | 未修改 | — | — |
Advice — 待人工复核。 当前 Pigsty 模板投影事实：OLTP: PG16–19 Beta 3 未修改；OLAP: PG16–19 Beta 3 未修改；CRIT: PG16–19 Beta 3 未修改；TINY: PG16–19 Beta 3 未修改。 未发现覆盖值，因此不推断 Pigsty 专属理由。
常见坑
- 在错误的主库、备库、发送端或订阅端角色上修改。
- 只看字节/时间配置，不监控真实复制延迟、槽位置与 worker 状态。
- 故障切换后新主库缺少与旧主库一致的容量或依赖。
- 用无限等待或无限 WAL 保留掩盖失效消费者。
关联参数
max_logical_replication_workers · max_sync_workers_per_subscription · max_worker_processes · max_replication_slots · max_active_replication_origins · hot_standby
参考资料
7 - max_repack_replication_slots
Fact — 官方简述译文：设置 REPACK 命令可使用的最大复制槽数量。
身份
类型,- 上游 pg_settings 类型
Context,- 修改后需要重启数据库
单位,- 原始单位
范围,- 最后在档版本的原始上下限
枚举值,- 非枚举类型记为 —
分类,- 上游分类
最后 boot 值,- 5
生命周期
| Fact | 值 |
|---|---|
| 首次观测 | PG19 Beta 3 |
| 在档版本 | PG19 Beta 3 |
| 移除版本 | 否 |
| 引入提交 | e76d8c749c31 — Reserve replication slots specifically for REPACK |
| 提交日期 | 2026-04-07 |
| Discussion | 讨论 1 |
默认值变迁
| 版本 | 原始 boot_val |
单位 | 人类可读值 |
|---|---|---|---|
| PG19 Beta 3 | 5 |
— | 5 |
机制详解
max_repack_replication_slots：设置 REPACK 命令可使用的最大复制槽数量。该值在服务器启动时固定，修改后必须安排受控重启。 本站在 PG19 Beta 3 实测到它；boot_val 是编译或初始化基线，并不能证明某个运行集群的当前有效值。
PG19 的 REPACK 命令可使用专用复制槽，在跟踪并发变更的同时重组关系。这个启动上限决定服务器最多支持多少此类槽；它与复制槽总预算、WAL sender 预算以及 WAL 保留造成的磁盘风险联动。
应与 max_replication_slots、max_wal_senders、wal_level、max_slot_wal_keep_size 一起理解。请在目标服务器检查 SHOW 与 pg_settings，确认 source 和 pending_restart，并在修改前后对比真实负载、日志和资源指标。
调优建议
Advice。 以下建议是工作负载起点，必须用真实测量验证。
| 场景 | 建议 |
|---|---|
| OLTP | 设定边界前要模拟正常故障转移与最坏复制延迟，并观察 sender 状态、保留 WAL、关机耗时和接收端追赶；为监控与计划切换保留足够容量。 |
| OLAP | 应计入大事务、批量装载、慢 apply 与远距离链路。较短超时虽能加快关机，却可能把恢复工作和不一致风险转移到下次启动。 |
| 小规格 | 限制槽和 sender 数量，监控 pg_wal 磁盘占用，并明确超时语义；分别在接收端健康与不可用时测试关机和重启。 |
Pigsty 取值
以下值来自固定 8 核、32 GiB、100 GiB SSD 夹具，并按 PG19 Beta 3 渲染当前 Pigsty 模板；这不表示 Pigsty 当前支持该历史或测试版本。
| 模板 | 有效值 | 与上游 boot 比较 | 源表达式 |
|---|---|---|---|
| OLTP | 未修改 | — | — |
| OLAP | 未修改 | — | — |
| CRIT | 未修改 | — | — |
| TINY | 未修改 | — | — |
Advice — 待人工复核。 当前 Pigsty 模板投影事实：OLTP: PG19 Beta 3 未修改；OLAP: PG19 Beta 3 未修改；CRIT: PG19 Beta 3 未修改；TINY: PG19 Beta 3 未修改。 未发现覆盖值，因此不推断 Pigsty 专属理由。
常见坑
- 把 max_repack_replication_slots 的实测 boot_val 当成初始化后或托管集群当前有效值的证明。
- 忽略 pg_settings 报告的 postmaster context，误以为修改会立即生效。
- 孤立修改该参数，没有检查关联上限、可观测性和回滚路径。
- 在生产中依赖测试版行为，却没有在 PostgreSQL 19 正式版发布后重新验证。
关联参数
max_replication_slots · max_wal_senders · wal_level · max_slot_wal_keep_size · wal_sender_shutdown_timeout
参考资料
8 - max_replication_slots
Fact — 官方简述译文：设置可同时定义的复制槽最大数量。
身份
类型,- 上游 pg_settings 类型
Context,- 修改后需要重启数据库
单位,- 原始单位
范围,- 最后在档版本的原始上下限
枚举值,- 非枚举类型记为 —
分类,- 上游分类
最后 boot 值,- 10
生命周期
| Fact | 值 |
|---|---|
| 首次观测 | PG9.4 |
| 在档版本 | PG9.4–19 Beta 3 |
| 移除版本 | 否 |
| 引入提交 | 858ec11858a9 — Introduce replication slots. |
| 提交日期 | 2014-01-31 |
| Discussion | — |
默认值变迁
| 版本 | 原始 boot_val |
单位 | 人类可读值 |
|---|---|---|---|
| PG9.4–9.6 | 0 |
— | 0 |
| PG10–19 Beta 3 | 10 |
— | 10 |
机制详解
PostgreSQL 在服务器启动时分配复制槽控制容量。物理槽可以为备库保留 WAL；逻辑槽还会为解码消费者保留 WAL 和系统目录可见性信息。
该值限制复制槽对象数量，而不是活动 WAL 发送连接数；后者由 max_wal_senders 单独限制。使用复制槽还要求 wal_level 至少为 replica。若将该值降到现有槽数量以下，服务器将无法启动。
没有活动进程的槽也不一定无害。持久的非活动槽可能保留 WAL，逻辑槽还可能持有 catalog_xmin，因此消费者生命周期和槽清单治理与数字上限同样重要。
调优建议
Advice。 以下建议是工作负载起点，必须用真实测量验证。
| 场景 | 建议 |
|---|---|
| OLTP | 按具名物理备库、逻辑订阅、CDC 消费者、备份或迁移工具、故障转移槽及创建余量核算。可保留少量缓冲，但较大上限必须配套所有者、过期和延迟监控。 |
| OLAP | 为逻辑消费者和迁移任务预留空间，同时注意高 WAL 批处理会放大废弃槽的代价。批任务前后应检查 restart_lsn 与 confirmed_flush_lsn。 |
| 小规格 | 将上限保持在真实消费者数量加有限余量附近。大值本身不会保留 WAL，却更容易产生无人治理的槽，在小磁盘上迅速演变为故障。 |
Pigsty 取值
以下值来自固定 8 核、32 GiB、100 GiB SSD 夹具，并按 PG19 Beta 3 渲染当前 Pigsty 模板；这不表示 Pigsty 当前支持该历史或测试版本。
| 模板 | 有效值 | 与上游 boot 比较 | 源表达式 |
|---|---|---|---|
| OLTP | 50 |
不同于 boot 值 | 50 |
| OLAP | 50 |
不同于 boot 值 | 50 |
| CRIT | 50 |
不同于 boot 值 | 50 |
| TINY | 50 |
不同于 boot 值 | 50 |
Advice — 待人工复核。 当前 Pigsty 模板投影事实：OLTP: PG9.4–19 Beta 3 = 50 (dcs)；OLAP: PG9.4–19 Beta 3 = 50 (dcs)；CRIT: PG9.4–19 Beta 3 = 50 (dcs)；TINY: PG9.4–19 Beta 3 = 50 (dcs)。 建议（待人工复核）——发布前应结合当前 Pigsty 模板及其实际支持的 PostgreSQL 版本确认运维意图。
常见坑
- 把复制槽数量上限与限制并发发送进程的 max_wal_senders 混淆。
- 将值降到现有复制槽数量以下，导致 PostgreSQL 无法启动。
- 认为非活动槽不会保留 WAL 或系统目录旧行版本。
- 提高上限却不监控 restart_lsn、catalog_xmin 和消费者健康。
- 实验时创建永久复制槽，结束后从不删除。
关联参数
max_wal_senders · max_slot_wal_keep_size · wal_level · idle_replication_slot_timeout · max_logical_replication_workers · primary_slot_name
参考资料
9 - max_slot_wal_keep_size
Fact — 官方简述译文：设置复制槽可保留的 WAL 最大大小。
身份
类型,- 上游 pg_settings 类型
Context,- 配置 reload 后生效
单位,- 原始单位
范围,- 最后在档版本的原始上下限
枚举值,- 非枚举类型记为 —
分类,- 上游分类
最后 boot 值,- -1 MB
生命周期
| Fact | 值 |
|---|---|
| 首次观测 | PG13 |
| 在档版本 | PG13–19 Beta 3 |
| 移除版本 | 否 |
| 引入提交 | c6550776394e — Allow users to limit storage reserved by replication slots |
| 提交日期 | 2020-04-07 |
| Discussion | 讨论 1 |
默认值变迁
| 版本 | 原始 boot_val |
单位 | 人类可读值 |
|---|---|---|---|
| PG13–19 Beta 3 | -1 |
MB |
-1 MB |
机制详解
执行检查点时，PostgreSQL 会比较复制槽的 restart_lsn 与当前 WAL 位置。默认值 -1 表示参数不设上限，因此停滞消费者可能保留足以写满 pg_wal 的 WAL。
设置有限值后，复制槽落后过多时所需段可被释放。槽的 wal_status 可能从 unreserved 变为 lost，消费者可能需要重新做基础备份或逻辑同步。该上限通过牺牲无限期可续传保证来保护主库磁盘。
限制在检查点时执行，因此既不即时，也不是精确字节硬上限。pg_replication_slots 提供 restart_lsn、wal_status、invalidation_reason 和 safe_wal_size，应在触顶前使用这些信号预警。
调优建议
Advice。 以下建议是工作负载起点，必须用真实测量验证。
| 场景 | 建议 |
|---|---|
| OLTP | 在 pg_wal 应急预算内设置有限值，并按峰值 WAL 速率乘以最大修复窗口推导。safe_wal_size 仍为正时就应告警，并为每个消费者记录重新同步路径。 |
| OLAP | 为预期的批量 WAL 峰值留出空间，但不要让上限形同无限。协调消费者与批任务，验证归档可用性，并在落后消费者耗尽磁盘预算之前暂停或修复它。 |
| 小规格 | 采用更严格的有限上限和较短修复目标。小卷环境通常应优先保护主库，而不是永远保证陈旧备库或 CDC 槽可续传。 |
Pigsty 取值
以下值来自固定 8 核、32 GiB、100 GiB SSD 夹具，并按 PG19 Beta 3 渲染当前 Pigsty 模板；这不表示 Pigsty 当前支持该历史或测试版本。
| 模板 | 有效值 | 与上游 boot 比较 | 源表达式 |
|---|---|---|---|
| OLTP | 30GB |
不同于 boot 值 | {{ ([pg_size_twentieth * 6, 3000])|min }}GB |
| OLAP | 30GB |
不同于 boot 值 | {{ ([pg_size_twentieth * 6, 3000])|min }}GB |
| CRIT | 30GB |
不同于 boot 值 | {{ ([pg_size_twentieth * 6, 3000])|min }}GB |
| TINY | 30GB |
不同于 boot 值 | {{ ([pg_size_twentieth * 6, 3000])|min }}GB |
Advice — 待人工复核。 当前 Pigsty 模板投影事实：OLTP: PG13–19 Beta 3 = 30GB (dcs)；OLAP: PG13–19 Beta 3 = 30GB (dcs)；CRIT: PG13–19 Beta 3 = 30GB (dcs)；TINY: PG13–19 Beta 3 = 30GB (dcs)。 建议（待人工复核）——发布前应结合当前 Pigsty 模板及其实际支持的 PostgreSQL 版本确认运维意图。
常见坑
- 保留 -1，却认为停滞复制槽不会写满磁盘。
- 把有限值当作即时硬上限，忽略检查点执行时机。
- 设置过小，在计划内批量任务期间使健康消费者失效。
- 认为所需 WAL 删除后消费者仍必然可以续传。
- 把该复制槽保留上限与 wal_keep_size 保留下限混淆。
关联参数
max_replication_slots · wal_keep_size · max_wal_size · idle_replication_slot_timeout · checkpoint_timeout · archive_mode
参考资料
10 - max_standby_archive_delay
Fact — 官方简述译文：设置热备处理归档 WAL 时，取消冲突查询前允许的最大延迟。
身份
类型,- 上游 pg_settings 类型
Context,- 配置 reload 后生效
单位,- 原始单位
范围,- 最后在档版本的原始上下限
枚举值,- 非枚举类型记为 —
分类,- 上游分类
最后 boot 值,- 30 s
生命周期
| Fact | 值 |
|---|---|
| 首次观测 | PG9.0（研究下界） |
| 在档版本 | PG9.0–19 Beta 3 |
| 移除版本 | 否 |
| 引入提交 | 不作断言：早于 PG9.0 研究边界 |
| 提交日期 | — |
| Discussion | — |
默认值变迁
| 版本 | 原始 boot_val |
单位 | 人类可读值 |
|---|---|---|---|
| PG9.0–19 Beta 3 | 30000 |
ms |
30 s |
机制详解
设置热备处理归档 WAL 时，取消冲突查询前允许的最大延迟。重新加载配置即可应用新值；已经开始的工作不会被追溯改变。
备库重放归档 WAL 时，恢复最多累计等待这么久再取消冲突查询。该预算针对重放进度，不会为每条查询重新发放；-1 可能让重放延迟无限增长。
应把 max_standby_archive_delay 与 max_standby_streaming_delay、hot_standby、hot_standby_feedback 一起监控和变更。先在对应角色与真实负载上验证，再按其 sighup context 选择会话修改、reload 或 restart；历史默认值并不等于当前有效值。
调优建议
Advice。 以下建议是工作负载起点，必须用真实测量验证。
| 场景 | 建议 |
|---|---|
| OLTP | 按主备拓扑、故障切换角色、复制槽/订阅数量与断连余量规划 max_standby_archive_delay；上线前验证主库写延迟、备库重放和磁盘保留的最坏情况。 |
| OLAP | 读备库与逻辑订阅常有长查询或大事务，应给重放/应用留明确上界，并监控延迟、worker 饱和、槽 restart_lsn 与冲突取消。 |
| 小规格 | 只配置真实需要的复制能力。少量节点也应设置有界超时与槽生命周期，不要用无限保留换取表面稳定。 |
Pigsty 取值
以下值来自固定 8 核、32 GiB、100 GiB SSD 夹具，并按 PG19 Beta 3 渲染当前 Pigsty 模板；这不表示 Pigsty 当前支持该历史或测试版本。
| 模板 | 有效值 | 与上游 boot 比较 | 源表达式 |
|---|---|---|---|
| OLTP | 10min |
不同于 boot 值 | 10min |
| OLAP | 10min |
不同于 boot 值 | 10min |
| CRIT | 10min |
不同于 boot 值 | 10min |
| TINY | 10min |
不同于 boot 值 | 10min |
Advice — 待人工复核。 当前 Pigsty 模板投影事实：OLTP: PG9.0–19 Beta 3 = 10min (dcs)；OLAP: PG9.0–19 Beta 3 = 10min (dcs)；CRIT: PG9.0–19 Beta 3 = 10min (dcs)；TINY: PG9.0–19 Beta 3 = 10min (dcs)。 建议（待人工复核）——编辑推断（待维护者人工复核）：该选择看起来意在备库从归档追赶时，在有界范围内偏向查询连续性；发布前应结合当前 Pigsty 模板、硬件夹具和运维保证复核。
常见坑
- 在错误的主库、备库、发送端或订阅端角色上修改。
- 只看字节/时间配置，不监控真实复制延迟、槽位置与 worker 状态。
- 故障切换后新主库缺少与旧主库一致的容量或依赖。
- 用无限等待或无限 WAL 保留掩盖失效消费者。
关联参数
max_standby_streaming_delay · hot_standby · hot_standby_feedback · recovery_min_apply_delay · primary_conninfo · primary_slot_name
参考资料
11 - max_standby_streaming_delay
Fact — 官方简述译文：设置热备处理流式 WAL 时，取消冲突查询前允许的最大延迟。
身份
类型,- 上游 pg_settings 类型
Context,- 配置 reload 后生效
单位,- 原始单位
范围,- 最后在档版本的原始上下限
枚举值,- 非枚举类型记为 —
分类,- 上游分类
最后 boot 值,- 30 s
生命周期
| Fact | 值 |
|---|---|
| 首次观测 | PG9.0（研究下界） |
| 在档版本 | PG9.0–19 Beta 3 |
| 移除版本 | 否 |
| 引入提交 | 不作断言：早于 PG9.0 研究边界 |
| 提交日期 | — |
| Discussion | — |
默认值变迁
| 版本 | 原始 boot_val |
单位 | 人类可读值 |
|---|---|---|---|
| PG9.0–19 Beta 3 | 30000 |
ms |
30 s |
机制详解
设置热备处理流式 WAL 时，取消冲突查询前允许的最大延迟。重新加载配置即可应用新值；已经开始的工作不会被追溯改变。
备库重放流式 WAL 时，恢复最多累计等待这么久再取消冲突查询。更大值偏向读连续性，却扩大复制延迟和恢复点暴露；hot_standby_feedback 可缓解部分快照冲突，但可能造成主库膨胀。
应把 max_standby_streaming_delay 与 max_standby_archive_delay、hot_standby、hot_standby_feedback 一起监控和变更。先在对应角色与真实负载上验证，再按其 sighup context 选择会话修改、reload 或 restart；历史默认值并不等于当前有效值。
调优建议
Advice。 以下建议是工作负载起点，必须用真实测量验证。
| 场景 | 建议 |
|---|---|
| OLTP | 按主备拓扑、故障切换角色、复制槽/订阅数量与断连余量规划 max_standby_streaming_delay；上线前验证主库写延迟、备库重放和磁盘保留的最坏情况。 |
| OLAP | 读备库与逻辑订阅常有长查询或大事务，应给重放/应用留明确上界，并监控延迟、worker 饱和、槽 restart_lsn 与冲突取消。 |
| 小规格 | 只配置真实需要的复制能力。少量节点也应设置有界超时与槽生命周期，不要用无限保留换取表面稳定。 |
Pigsty 取值
以下值来自固定 8 核、32 GiB、100 GiB SSD 夹具，并按 PG19 Beta 3 渲染当前 Pigsty 模板；这不表示 Pigsty 当前支持该历史或测试版本。
| 模板 | 有效值 | 与上游 boot 比较 | 源表达式 |
|---|---|---|---|
| OLTP | 3min |
不同于 boot 值 | 3min |
| OLAP | 3min |
不同于 boot 值 | 3min |
| CRIT | 3min |
不同于 boot 值 | 3min |
| TINY | 3min |
不同于 boot 值 | 3min |
Advice — 待人工复核。 当前 Pigsty 模板投影事实：OLTP: PG9.0–19 Beta 3 = 3min (dcs)；OLAP: PG9.0–19 Beta 3 = 3min (dcs)；CRIT: PG9.0–19 Beta 3 = 3min (dcs)；TINY: PG9.0–19 Beta 3 = 3min (dcs)。 建议（待人工复核）——编辑推断（待维护者人工复核）：该选择看起来意在允许流复制备库运行短分析查询，同时避免无限重放延迟；发布前应结合当前 Pigsty 模板、硬件夹具和运维保证复核。
常见坑
- 在错误的主库、备库、发送端或订阅端角色上修改。
- 只看字节/时间配置，不监控真实复制延迟、槽位置与 worker 状态。
- 故障切换后新主库缺少与旧主库一致的容量或依赖。
- 用无限等待或无限 WAL 保留掩盖失效消费者。
关联参数
max_standby_archive_delay · hot_standby · hot_standby_feedback · recovery_min_apply_delay · in_hot_standby · primary_conninfo
参考资料
12 - max_sync_workers_per_subscription
Fact — 官方简述译文：设置每个订阅的表同步 worker 最大数量。
身份
类型,- 上游 pg_settings 类型
Context,- 配置 reload 后生效
单位,- 原始单位
范围,- 最后在档版本的原始上下限
枚举值,- 非枚举类型记为 —
分类,- 上游分类
最后 boot 值,- 2
生命周期
| Fact | 值 |
|---|---|
| 首次观测 | PG10 |
| 在档版本 | PG10–19 Beta 3 |
| 移除版本 | 否 |
| 引入提交 | 7c4f52409a8c — Logical replication support for initial data copy |
| 提交日期 | 2017-03-23 |
| Discussion | — |
默认值变迁
| 版本 | 原始 boot_val |
单位 | 人类可读值 |
|---|---|---|---|
| PG10–19 Beta 3 | 2 |
— | 2 |
机制详解
设置每个订阅的表同步 worker 最大数量。重新加载配置即可应用新值；已经开始的工作不会被追溯改变。
它只在对应的发送端、主库、备库或订阅端角色上生效；级联复制与故障切换会改变服务器角色，因此相关容量和依赖应在所有候选节点一致规划。
应把 max_sync_workers_per_subscription 与 max_logical_replication_workers、max_parallel_apply_workers_per_subscription、max_worker_processes 一起监控和变更。先在对应角色与真实负载上验证，再按其 sighup context 选择会话修改、reload 或 restart；历史默认值并不等于当前有效值。
调优建议
Advice。 以下建议是工作负载起点，必须用真实测量验证。
| 场景 | 建议 |
|---|---|
| OLTP | 按主备拓扑、故障切换角色、复制槽/订阅数量与断连余量规划 max_sync_workers_per_subscription；上线前验证主库写延迟、备库重放和磁盘保留的最坏情况。 |
| OLAP | 读备库与逻辑订阅常有长查询或大事务，应给重放/应用留明确上界，并监控延迟、worker 饱和、槽 restart_lsn 与冲突取消。 |
| 小规格 | 只配置真实需要的复制能力。少量节点也应设置有界超时与槽生命周期，不要用无限保留换取表面稳定。 |
Pigsty 取值
以下值来自固定 8 核、32 GiB、100 GiB SSD 夹具，并按 PG19 Beta 3 渲染当前 Pigsty 模板；这不表示 Pigsty 当前支持该历史或测试版本。
| 模板 | 有效值 | 与上游 boot 比较 | 源表达式 |
|---|---|---|---|
| OLTP | 6 |
不同于 boot 值 | 6 |
| OLAP | 6 |
不同于 boot 值 | 6 |
| CRIT | 6 |
不同于 boot 值 | 6 |
| TINY | 6 |
不同于 boot 值 | 6 |
Advice — 待人工复核。 当前 Pigsty 模板投影事实：OLTP: PG10–19 Beta 3 = 6 (dcs)；OLAP: PG10–19 Beta 3 = 6 (dcs)；CRIT: PG10–19 Beta 3 = 6 (dcs)；TINY: PG10–19 Beta 3 = 6 (dcs)。 建议（待人工复核）——编辑推断（待维护者人工复核）：该选择看起来意在在全局 worker 预算内加速逻辑复制初始表复制；发布前应结合当前 Pigsty 模板、硬件夹具和运维保证复核。
常见坑
- 在错误的主库、备库、发送端或订阅端角色上修改。
- 只看字节/时间配置，不监控真实复制延迟、槽位置与 worker 状态。
- 故障切换后新主库缺少与旧主库一致的容量或依赖。
- 用无限等待或无限 WAL 保留掩盖失效消费者。
关联参数
max_logical_replication_workers · max_parallel_apply_workers_per_subscription · max_worker_processes · max_replication_slots · max_active_replication_origins · hot_standby
参考资料
13 - max_wal_senders
Fact — 官方简述译文：设置可同时运行的 WAL sender 进程最大数量。
身份
类型,- 上游 pg_settings 类型
Context,- 修改后需要重启数据库
单位,- 原始单位
范围,- 最后在档版本的原始上下限
枚举值,- 非枚举类型记为 —
分类,- 上游分类
最后 boot 值,- 10
生命周期
| Fact | 值 |
|---|---|
| 首次观测 | PG9.0（研究下界） |
| 在档版本 | PG9.0–19 Beta 3 |
| 移除版本 | 否 |
| 引入提交 | 不作断言：早于 PG9.0 研究边界 |
| 提交日期 | — |
| Discussion | — |
默认值变迁
| 版本 | 原始 boot_val |
单位 | 人类可读值 |
|---|---|---|---|
| PG9.0–9.6 | 0 |
— | 0 |
| PG10–19 Beta 3 | 10 |
— | 10 |
机制详解
设置可同时运行的 WAL sender 进程最大数量。该值在服务器启动时固定，修改后必须重启。
每个流复制备库、流式基础备份或逻辑复制连接都可能占用 WAL sender。零会禁止发送；断开的客户端在超时前仍可能占槽，而且备库为支持查询应至少配置与主库相同的数量。
应把 max_wal_senders 与 wal_level、max_replication_slots、archive_mode 一起监控和变更。先在对应角色与真实负载上验证，再按其 postmaster context 选择会话修改、reload 或 restart；历史默认值并不等于当前有效值。
调优建议
Advice。 以下建议是工作负载起点，必须用真实测量验证。
| 场景 | 建议 |
|---|---|
| OLTP | 按主备拓扑、故障切换角色、复制槽/订阅数量与断连余量规划 max_wal_senders；上线前验证主库写延迟、备库重放和磁盘保留的最坏情况。 |
| OLAP | 读备库与逻辑订阅常有长查询或大事务，应给重放/应用留明确上界，并监控延迟、worker 饱和、槽 restart_lsn 与冲突取消。 |
| 小规格 | 只配置真实需要的复制能力。少量节点也应设置有界超时与槽生命周期，不要用无限保留换取表面稳定。 |
Pigsty 取值
以下值来自固定 8 核、32 GiB、100 GiB SSD 夹具，并按 PG19 Beta 3 渲染当前 Pigsty 模板；这不表示 Pigsty 当前支持该历史或测试版本。
| 模板 | 有效值 | 与上游 boot 比较 | 源表达式 |
|---|---|---|---|
| OLTP | 50 |
不同于 boot 值 | 50 |
| OLAP | 50 |
不同于 boot 值 | 50 |
| CRIT | 50 |
不同于 boot 值 | 50 |
| TINY | 50 |
不同于 boot 值 | 50 |
Advice — 待人工复核。 当前 Pigsty 模板投影事实：OLTP: PG9.0–19 Beta 3 = 50 (dcs)；OLAP: PG9.0–19 Beta 3 = 50 (dcs)；CRIT: PG9.0–19 Beta 3 = 50 (dcs)；TINY: PG9.0–19 Beta 3 = 50 (dcs)。 建议（待人工复核）——编辑推断（待维护者人工复核）：该选择看起来意在为备库、备份和逻辑客户端预留连接余量；发布前应结合当前 Pigsty 模板、硬件夹具和运维保证复核。
常见坑
- 在错误的主库、备库、发送端或订阅端角色上修改。
- 只看字节/时间配置，不监控真实复制延迟、槽位置与 worker 状态。
- 故障切换后新主库缺少与旧主库一致的容量或依赖。
- 用无限等待或无限 WAL 保留掩盖失效消费者。
关联参数
wal_level · max_replication_slots · archive_mode · wal_log_hints · output_plugin_libraries · wal_sender_timeout
参考资料
14 - output_plugin_libraries
Fact — 官方简述译文：列出可作为逻辑解码输出插件指定的库。
身份
类型,- 上游 pg_settings 类型
Context,- 超级用户可在运行时修改
单位,- 原始单位
范围,- 最后在档版本的原始上下限
枚举值,- 非枚举类型记为 —
分类,- 上游分类
最后 boot 值,- pgoutput, test_decoding
生命周期
| Fact | 值 |
|---|---|
| 首次观测 | PG14 |
| 在档版本 | PG14–19 Beta 3 |
| 移除版本 | 否 |
| 引入提交 | bf3842a64f5d — Add an output_plugin_libraries GUC to bless trusted output plugins |
| 提交日期 | 2026-08-10 |
| Discussion | — |
默认值变迁
| 版本 | 原始 boot_val |
单位 | 人类可读值 |
|---|---|---|---|
| PG14–19 Beta 3 | pgoutput, test_decoding |
— | pgoutput, test_decoding |
机制详解
列出可作为逻辑解码输出插件指定的库。超级用户或获授 SET 权限的角色可在相应的会话或配置作用域中修改它。
逻辑解码只接受该服务端白名单中的输出插件库名，按 LOAD 规则解释并要求插件名精确匹配。加入库是信任决策，因为插件代码在服务器进程内部执行。
应把 output_plugin_libraries 与 wal_level、max_wal_senders、max_replication_slots 一起监控和变更。先在对应角色与真实负载上验证，再按其 superuser context 选择会话修改、reload 或 restart；历史默认值并不等于当前有效值。
调优建议
Advice。 以下建议是工作负载起点，必须用真实测量验证。
| 场景 | 建议 |
|---|---|
| OLTP | 只列出已安装、已审计且确有消费者使用的输出插件；修改后用最低权限逻辑复制用户验证，并把插件升级纳入服务器发布。 |
| OLAP | ETL 解码插件同样是进程内代码，不要为方便使用通配或宽泛路径；验证大事务的内存、WAL 保留与插件输出。 |
| 小规格 | 不做逻辑解码就保留内置小白名单；增加 wal2json 等插件前确认包来源、版本兼容与维护责任。 |
Pigsty 取值
以下值来自固定 8 核、32 GiB、100 GiB SSD 夹具，并按 PG19 Beta 3 渲染当前 Pigsty 模板；这不表示 Pigsty 当前支持该历史或测试版本。
| 模板 | 有效值 | 与上游 boot 比较 | 源表达式 |
|---|---|---|---|
| OLTP | pgoutput, test_decoding, wal2json |
不同于 boot 值 | 'pgoutput, test_decoding, wal2json' |
| OLAP | pgoutput, test_decoding, wal2json |
不同于 boot 值 | 'pgoutput, test_decoding, wal2json' |
| CRIT | pgoutput, test_decoding, wal2json |
不同于 boot 值 | 'pgoutput, test_decoding, wal2json' |
| TINY | pgoutput, test_decoding, wal2json |
不同于 boot 值 | 'pgoutput, test_decoding, wal2json' |
Advice — 待人工复核。 当前 Pigsty 模板投影事实：OLTP: PG14–19 Beta 3 = pgoutput, test_decoding, wal2json (dcs)；OLAP: PG14–19 Beta 3 = pgoutput, test_decoding, wal2json (dcs)；CRIT: PG14–19 Beta 3 = pgoutput, test_decoding, wal2json (dcs)；TINY: PG14–19 Beta 3 = pgoutput, test_decoding, wal2json (dcs)。 建议（待人工复核）——编辑推断（待维护者人工复核）：该选择看起来意在在保持明确小型白名单的同时提供 wal2json；发布前应结合当前 Pigsty 模板、硬件夹具和运维保证复核。
常见坑
- 在错误的主库、备库、发送端或订阅端角色上修改。
- 只看字节/时间配置，不监控真实复制延迟、槽位置与 worker 状态。
- 故障切换后新主库缺少与旧主库一致的容量或依赖。
- 用无限等待或无限 WAL 保留掩盖失效消费者。
关联参数
wal_level · max_wal_senders · max_replication_slots · archive_mode · wal_log_hints · shared_preload_libraries
参考资料
15 - primary_conninfo
Fact — 官方简述译文：设置连接发送端服务器时使用的连接字符串。
身份
类型,- 上游 pg_settings 类型
Context,- 配置 reload 后生效
单位,- 原始单位
范围,- 最后在档版本的原始上下限
枚举值,- 非枚举类型记为 —
分类,- 上游分类
最后 boot 值,- empty string
生命周期
| Fact | 值 |
|---|---|
| 首次观测 | PG12 |
| 在档版本 | PG12–19 Beta 3 |
| 移除版本 | 否 |
| 引入提交 | 2dedf4d9a899 — Integrate recovery.conf into postgresql.conf |
| 提交日期 | 2018-11-25 |
| Discussion | 讨论 1 |
默认值变迁
| 版本 | 原始 boot_val |
单位 | 人类可读值 |
|---|---|---|---|
| PG12–19 Beta 3 | "" |
— | empty string |
机制详解
设置连接发送端服务器时使用的连接字符串。重新加载配置即可应用新值；已经开始的工作不会被追溯改变。
WAL receiver 用这条 libpq 连接串访问上游发送端。重载非空新值会重启 receiver；凭据应尽量放入受保护的 passfile，复制槽同步还要求提供 dbname。
应把 primary_conninfo 与 max_wal_senders、max_replication_slots、wal_level 一起监控和变更。先在对应角色与真实负载上验证，再按其 sighup context 选择会话修改、reload 或 restart；历史默认值并不等于当前有效值。
调优建议
Advice。 以下建议是工作负载起点，必须用真实测量验证。
| 场景 | 建议 |
|---|---|
| OLTP | 按主备拓扑、故障切换角色、复制槽/订阅数量与断连余量规划 primary_conninfo；上线前验证主库写延迟、备库重放和磁盘保留的最坏情况。 |
| OLAP | 读备库与逻辑订阅常有长查询或大事务，应给重放/应用留明确上界，并监控延迟、worker 饱和、槽 restart_lsn 与冲突取消。 |
| 小规格 | 只配置真实需要的复制能力。少量节点也应设置有界超时与槽生命周期，不要用无限保留换取表面稳定。 |
Pigsty 取值
以下值来自固定 8 核、32 GiB、100 GiB SSD 夹具，并按 PG19 Beta 3 渲染当前 Pigsty 模板；这不表示 Pigsty 当前支持该历史或测试版本。
| 模板 | 有效值 | 与上游 boot 比较 | 源表达式 |
|---|---|---|---|
| OLTP | 未修改 | — | — |
| OLAP | 未修改 | — | — |
| CRIT | 未修改 | — | — |
| TINY | 未修改 | — | — |
Advice — 待人工复核。 当前 Pigsty 模板投影事实：OLTP: PG12–19 Beta 3 未修改；OLAP: PG12–19 Beta 3 未修改；CRIT: PG12–19 Beta 3 未修改；TINY: PG12–19 Beta 3 未修改。 未发现覆盖值，因此不推断 Pigsty 专属理由。
常见坑
- 把明文密码写进可被广泛读取的配置或诊断。
- 复制槽同步需要 dbname 时遗漏它。
- 未协调时间线与槽状态就更换上游身份。
- 在错误的主库、备库、发送端或订阅端角色上修改。
- 只看字节/时间配置，不监控真实复制延迟、槽位置与 worker 状态。
关联参数
max_wal_senders · max_replication_slots · wal_level · wal_sender_timeout · max_slot_wal_keep_size · primary_slot_name
参考资料
16 - primary_slot_name
Fact — 官方简述译文：设置连接发送端服务器时使用的复制槽名称。
身份
类型,- 上游 pg_settings 类型
Context,- 配置 reload 后生效
单位,- 原始单位
范围,- 最后在档版本的原始上下限
枚举值,- 非枚举类型记为 —
分类,- 上游分类
最后 boot 值,- empty string
生命周期
| Fact | 值 |
|---|---|
| 首次观测 | PG12 |
| 在档版本 | PG12–19 Beta 3 |
| 移除版本 | 否 |
| 引入提交 | 2dedf4d9a899 — Integrate recovery.conf into postgresql.conf |
| 提交日期 | 2018-11-25 |
| Discussion | 讨论 1 |
默认值变迁
| 版本 | 原始 boot_val |
单位 | 人类可读值 |
|---|---|---|---|
| PG12–19 Beta 3 | "" |
— | empty string |
机制详解
设置连接发送端服务器时使用的复制槽名称。重新加载配置即可应用新值；已经开始的工作不会被追溯改变。
Receiver 指定上游已有的物理槽，使发送端保留该备库所需 WAL。它提高断连后的连续性，却把磁盘保留风险转移到主库，故障切换时还必须协调槽生命周期。
应把 primary_slot_name 与 wal_keep_segments、wal_keep_size、wal_segment_size 一起监控和变更。先在对应角色与真实负载上验证，再按其 sighup context 选择会话修改、reload 或 restart；历史默认值并不等于当前有效值。
调优建议
Advice。 以下建议是工作负载起点，必须用真实测量验证。
| 场景 | 建议 |
|---|---|
| OLTP | 按主备拓扑、故障切换角色、复制槽/订阅数量与断连余量规划 primary_slot_name；上线前验证主库写延迟、备库重放和磁盘保留的最坏情况。 |
| OLAP | 读备库与逻辑订阅常有长查询或大事务，应给重放/应用留明确上界，并监控延迟、worker 饱和、槽 restart_lsn 与冲突取消。 |
| 小规格 | 只配置真实需要的复制能力。少量节点也应设置有界超时与槽生命周期，不要用无限保留换取表面稳定。 |
Pigsty 取值
以下值来自固定 8 核、32 GiB、100 GiB SSD 夹具，并按 PG19 Beta 3 渲染当前 Pigsty 模板；这不表示 Pigsty 当前支持该历史或测试版本。
| 模板 | 有效值 | 与上游 boot 比较 | 源表达式 |
|---|---|---|---|
| OLTP | 未修改 | — | — |
| OLAP | 未修改 | — | — |
| CRIT | 未修改 | — | — |
| TINY | 未修改 | — | — |
Advice — 待人工复核。 当前 Pigsty 模板投影事实：OLTP: PG12–19 Beta 3 未修改；OLAP: PG12–19 Beta 3 未修改；CRIT: PG12–19 Beta 3 未修改；TINY: PG12–19 Beta 3 未修改。 未发现覆盖值，因此不推断 Pigsty 专属理由。
常见坑
- 创建槽却不监控 restart_lsn 与主库磁盘。
- 故障切换时未证明消费者位置就删除或复用槽。
- 误以为复制槽本身会归档或备份 WAL。
- 在错误的主库、备库、发送端或订阅端角色上修改。
- 只看字节/时间配置，不监控真实复制延迟、槽位置与 worker 状态。
关联参数
wal_keep_segments · wal_keep_size · wal_segment_size · max_slot_wal_keep_size · max_wal_size · idle_replication_slot_timeout
参考资料
17 - promote_trigger_file
Fact — 官方简述译文：指定一个文件，其出现会使备库结束恢复。
身份
类型,- 上游 pg_settings 类型
Context,- 配置 reload 后生效
单位,- 原始单位
范围,- 最后在档版本的原始上下限
枚举值,- 非枚举类型记为 —
分类,- 上游分类
最后 boot 值,- empty string
生命周期
| Fact | 值 |
|---|---|
| 首次观测 | PG12 |
| 在档版本 | PG12–15 |
| 移除版本 | PG16 |
| 引入提交 | 2dedf4d9a899 — Integrate recovery.conf into postgresql.conf |
| 提交日期 | 2018-11-25 |
| Discussion | 讨论 1 |
默认值变迁
| 版本 | 原始 boot_val |
单位 | 人类可读值 |
|---|---|---|---|
| PG12–15 | "" |
— | empty string |
机制详解
指定一个文件，其出现会使备库结束恢复。该参数在 PG15 仍存在，并从 PG16 起不再被识别。PostgreSQL 16 移除了触发文件机制；应由 HA 控制器调用 pg_ctl promote 或 pg_promote()。
该机制存在时，恢复进程监视指定路径并在文件出现后提升。残留文件、竞态与共享存储语义使编排脆弱；PostgreSQL 16 移除了这一设置。
升级前应联合检查 hot_standby、hot_standby_feedback、max_standby_archive_delay，从配置、ALTER SYSTEM、角色/数据库设置和自动化模板中删除旧名，并先验证替代机制再启动 PG16+。
调优建议
Advice。 以下建议是工作负载起点，必须用真实测量验证。
| 场景 | 建议 |
|---|---|
| OLTP | 不要在 PG16+ 调优或继续下发 promote_trigger_file。PostgreSQL 16 移除了触发文件机制；应由 HA 控制器调用 pg_ctl promote 或 pg_promote()。升级前扫描所有配置层并做业务回归。 |
| OLAP | 迁移方案与 OLTP 相同；另外在长批处理、备库或大对象/扩展工作流中验证新机制，不要假定删除旧开关会保留旧行为。 |
| 小规格 | 直接删除旧配置并采用受支持替代项；若没有真实兼容需求，不要用脚本伪造旧行为。 |
Pigsty 取值
以下值来自固定 8 核、32 GiB、100 GiB SSD 夹具，并按 PG15 渲染当前 Pigsty 模板；这不表示 Pigsty 当前支持该历史或测试版本。
| 模板 | 有效值 | 与上游 boot 比较 | 源表达式 |
|---|---|---|---|
| OLTP | 未修改 | — | — |
| OLAP | 未修改 | — | — |
| CRIT | 未修改 | — | — |
| TINY | 未修改 | — | — |
Advice — 待人工复核。 当前 Pigsty 模板投影事实：OLTP: PG12–15 未修改；OLAP: PG12–15 未修改；CRIT: PG12–15 未修改；TINY: PG12–15 未修改。 未发现覆盖值，因此不推断 Pigsty 专属理由。
常见坑
- 在 PG16+ 配置中继续下发未知参数 promote_trigger_file。
- 只删除参数名，却未迁移依赖它的应用行为。
- 把历史默认值当作新版本替代机制的默认值。
- 遗漏 ALTER SYSTEM、角色/数据库设置或自动化模板中的旧条目。
关联参数
hot_standby · hot_standby_feedback · max_standby_archive_delay · max_standby_streaming_delay · primary_conninfo · primary_slot_name
参考资料
18 - recovery_min_apply_delay
Fact — 官方简述译文：设置恢复期间应用变更的最小延迟。
身份
类型,- 上游 pg_settings 类型
Context,- 配置 reload 后生效
单位,- 原始单位
范围,- 最后在档版本的原始上下限
枚举值,- 非枚举类型记为 —
分类,- 上游分类
最后 boot 值,- 0 ms
生命周期
| Fact | 值 |
|---|---|
| 首次观测 | PG12 |
| 在档版本 | PG12–19 Beta 3 |
| 移除版本 | 否 |
| 引入提交 | 2dedf4d9a899 — Integrate recovery.conf into postgresql.conf |
| 提交日期 | 2018-11-25 |
| Discussion | 讨论 1 |
默认值变迁
| 版本 | 原始 boot_val |
单位 | 人类可读值 |
|---|---|---|---|
| PG12–19 Beta 3 | 0 |
ms |
0 ms |
机制详解
设置恢复期间应用变更的最小延迟。重新加载配置即可应用新值；已经开始的工作不会被追溯改变。
备库会把每个事务 commit 的重放推迟到主库提交时间之后的指定时长。网络/级联延迟计入其中，时钟也会影响结果；synchronous_commit=remote_apply 会让主库提交一起等待这段人为延迟。
应把 recovery_min_apply_delay 与 max_standby_archive_delay、max_standby_streaming_delay、hot_standby 一起监控和变更。先在对应角色与真实负载上验证，再按其 sighup context 选择会话修改、reload 或 restart；历史默认值并不等于当前有效值。
调优建议
Advice。 以下建议是工作负载起点，必须用真实测量验证。
| 场景 | 建议 |
|---|---|
| OLTP | 按主备拓扑、故障切换角色、复制槽/订阅数量与断连余量规划 recovery_min_apply_delay；上线前验证主库写延迟、备库重放和磁盘保留的最坏情况。 |
| OLAP | 读备库与逻辑订阅常有长查询或大事务，应给重放/应用留明确上界，并监控延迟、worker 饱和、槽 restart_lsn 与冲突取消。 |
| 小规格 | 只配置真实需要的复制能力。少量节点也应设置有界超时与槽生命周期，不要用无限保留换取表面稳定。 |
Pigsty 取值
以下值来自固定 8 核、32 GiB、100 GiB SSD 夹具，并按 PG19 Beta 3 渲染当前 Pigsty 模板；这不表示 Pigsty 当前支持该历史或测试版本。
| 模板 | 有效值 | 与上游 boot 比较 | 源表达式 |
|---|---|---|---|
| OLTP | 未修改 | — | — |
| OLAP | 未修改 | — | — |
| CRIT | 未修改 | — | — |
| TINY | 未修改 | — | — |
Advice — 待人工复核。 当前 Pigsty 模板投影事实：OLTP: PG12–19 Beta 3 未修改；OLAP: PG12–19 Beta 3 未修改；CRIT: PG12–19 Beta 3 未修改；TINY: PG12–19 Beta 3 未修改。 未发现覆盖值，因此不推断 Pigsty 专属理由。
常见坑
- 在错误的主库、备库、发送端或订阅端角色上修改。
- 只看字节/时间配置，不监控真实复制延迟、槽位置与 worker 状态。
- 故障切换后新主库缺少与旧主库一致的容量或依赖。
- 用无限等待或无限 WAL 保留掩盖失效消费者。
关联参数
max_standby_archive_delay · max_standby_streaming_delay · hot_standby · hot_standby_feedback · primary_conninfo · primary_slot_name
参考资料
19 - replication_timeout
Fact — 官方简述译文：设置等待 WAL 复制活动的最长时间。
身份
类型,- 上游 pg_settings 类型
Context,- 配置 reload 后生效
单位,- 原始单位
范围,- 最后在档版本的原始上下限
枚举值,- 非枚举类型记为 —
分类,- 上游分类
最后 boot 值,- 1 min
生命周期
| Fact | 值 |
|---|---|
| 首次观测 | PG9.1 |
| 在档版本 | PG9.1–9.2 |
| 移除版本 | PG9.3 |
| 引入提交 | 754baa21f723 — Automatically terminate replication connections that are idle for more than replication_timeout (a new GUC) milliseconds. The TCP timeout is often too long, you want the master to notice a dead connection much sooner. People complained about that in 9.0 too, but with synchronous replication it’s even more important to notice dead connections promptly. |
| 提交日期 | 2011-03-30 |
| Discussion | — |
默认值变迁
| 版本 | 原始 boot_val |
单位 | 人类可读值 |
|---|---|---|---|
| PG9.1–9.2 | 60000 |
ms |
1 min |
机制详解
replication_timeout：设置等待 WAL 复制活动的最长时间。重新加载配置即可让服务器采用新值，无需完整重启。 本站在 PG9.1–9.2 实测到它；boot_val 是编译或初始化基线，并不能证明某个运行集群的当前有效值。
这是早期流复制中由发送端终止不活跃连接的超时。PG9.3 将其改名为 wal_sender_timeout；接收端故障检测由 wal_receiver_timeout 独立控制，迁移时必须分清计时器属于连接哪一端。
应与 wal_sender_timeout、wal_receiver_timeout、wal_receiver_status_interval、max_wal_senders 一起理解。请在目标服务器检查 SHOW 与 pg_settings，确认 source 和 pending_restart，并在修改前后对比真实负载、日志和资源指标。
调优建议
Advice。 以下建议是工作负载起点，必须用真实测量验证。
| 场景 | 建议 |
|---|---|
| OLTP | 不要把这个已退出的名称加入现代 OLTP 配置。应把原意迁移到文档给出的后继参数，在连接与写并发下验证，并清理仍会输出旧名称的自动化。 |
| OLAP | 升级分析型环境前应盘点所有生成配置，把旧控制映射到后继项，并比较执行计划、吞吐、WAL 或日志行为；不能假设旧数值可直接搬用。 |
| 小规格 | 记录旧覆盖存在的原因后将其删除。小节点应先采用后继参数默认值，实测后再调整；未知的启动参数可能直接阻止服务器启动。 |
Pigsty 取值
以下值来自固定 8 核、32 GiB、100 GiB SSD 夹具，并按 PG9.2 渲染当前 Pigsty 模板；这不表示 Pigsty 当前支持该历史或测试版本。
| 模板 | 有效值 | 与上游 boot 比较 | 源表达式 |
|---|---|---|---|
| OLTP | 未修改 | — | — |
| OLAP | 未修改 | — | — |
| CRIT | 未修改 | — | — |
| TINY | 未修改 | — | — |
Advice — 待人工复核。 当前 Pigsty 模板投影事实：OLTP: PG9.1–9.2 未修改；OLAP: PG9.1–9.2 未修改；CRIT: PG9.1–9.2 未修改；TINY: PG9.1–9.2 未修改。 未发现覆盖值，因此不推断 Pigsty 专属理由。
常见坑
- 把 replication_timeout 的实测 boot_val 当成初始化后或托管集群当前有效值的证明。
- 忽略 pg_settings 报告的 sighup context，误以为修改会立即生效。
- 孤立修改该参数，没有检查关联上限、可观测性和回滚路径。
- 把已移除名称复制到现代 postgresql.conf，而没有迁移到文档给出的后继参数。
关联参数
wal_sender_timeout · wal_receiver_timeout · wal_receiver_status_interval · max_wal_senders
参考资料
20 - sync_replication_slots
Fact — 官方简述译文：允许物理备库从主库同步逻辑故障转移复制槽。
身份
类型,- 上游 pg_settings 类型
Context,- 配置 reload 后生效
单位,- 原始单位
范围,- 最后在档版本的原始上下限
枚举值,- 非枚举类型记为 —
分类,- 上游分类
最后 boot 值,- off
生命周期
| Fact | 值 |
|---|---|
| 首次观测 | PG17 |
| 在档版本 | PG17–19 Beta 3 |
| 移除版本 | 否 |
| 引入提交 | 93db6cbda037 — Add a new slot sync worker to synchronize logical slots. |
| 提交日期 | 2024-02-22 |
| Discussion | 讨论 1 |
默认值变迁
| 版本 | 原始 boot_val |
单位 | 人类可读值 |
|---|---|---|---|
| PG17–19 Beta 3 | off |
— | off |
机制详解
在物理备库启用 slotsync worker，从主库复制逻辑 failover slot 状态。重新加载配置即可应用新值。
同步要求主备之间存在物理复制槽（备库设置 primary_slot_name）、备库开启 hot_standby_feedback，并在 primary_conninfo 中提供有效 dbname；源逻辑槽还必须启用 failover。
槽状态是异步复制的。主库应把该备库的物理槽列入 synchronized_standby_slots，避免订阅者跑在故障转移备库之前；提升前必须验证每个必需槽已同步且可用于切换。
调优建议
Advice。 以下建议是工作负载起点，必须用真实测量验证。
| 场景 | 建议 |
|---|---|
| OLTP | 只在完整的逻辑故障转移设计中启用。自动检查所有前提，并在必需 failover slot 尚未同步或存在冲突时阻止计划提升。 |
| OLAP | 大事务与延迟备库会扩大同步滞后；应联合监控订阅者确认位置、备库重放、物理槽保留与 catalog horizon。 |
| 小规格 | 不要仅因开关存在就启用。小型部署同样需要永久物理槽、hot_standby_feedback、dbname、保留上限和经过验证的切换 runbook。 |
Pigsty 取值
以下值来自固定 8 核、32 GiB、100 GiB SSD 夹具，并按 PG19 Beta 3 渲染当前 Pigsty 模板；这不表示 Pigsty 当前支持该历史或测试版本。
| 模板 | 有效值 | 与上游 boot 比较 | 源表达式 |
|---|---|---|---|
| OLTP | true |
不同于 boot 值 | on |
| OLAP | true |
不同于 boot 值 | on |
| CRIT | true |
不同于 boot 值 | on |
| TINY | true |
不同于 boot 值 | on |
Advice — 待人工复核。 当前 Pigsty 模板投影事实：OLTP: PG17–19 Beta 3 = True (dcs)；OLAP: PG17–19 Beta 3 = True (dcs)；CRIT: PG17–19 Beta 3 = True (dcs)；TINY: PG17–19 Beta 3 = True (dcs)。 建议（待人工复核）——编辑推断（待维护者人工复核）：该选择看起来意在在物理备库准备逻辑故障转移槽，以支持受控切换；发布前应结合当前 Pigsty 模板、硬件夹具和运维保证复核。
常见坑
- 未设置 primary_slot_name、缺少强制物理槽时就启用。
- hot_standby_feedback 仍为 off，无法为同步逻辑槽安全保留 catalog 行。
- primary_conninfo 中遗漏 dbname。
- 源逻辑槽未启用 failover，却期待它被同步。
- 未确认每个必需槽已同步且没有落后于订阅者就提升。
关联参数
primary_slot_name · hot_standby_feedback · primary_conninfo · synchronized_standby_slots · max_replication_slots · max_slot_wal_keep_size
参考资料
21 - synchronized_standby_slots
Fact — 官方简述译文：列出逻辑 WAL sender 必须等待的流复制备库槽。
身份
类型,- 上游 pg_settings 类型
Context,- 配置 reload 后生效
单位,- 原始单位
范围,- 最后在档版本的原始上下限
枚举值,- 非枚举类型记为 —
分类,- 上游分类
最后 boot 值,- empty string
生命周期
| Fact | 值 |
|---|---|
| 首次观测 | PG17 |
| 在档版本 | PG17–19 Beta 3 |
| 移除版本 | 否 |
| 引入提交 | 0f934b0739ad — Rename standby_slot_names to synchronized_standby_slots. |
| 提交日期 | 2024-07-01 |
| Discussion | 讨论 1 |
默认值变迁
| 版本 | 原始 boot_val |
单位 | 人类可读值 |
|---|---|---|---|
| PG17–19 Beta 3 | "" |
— | empty string |
机制详解
列出逻辑 WAL sender 必须等待的流复制备库槽。重新加载配置即可应用新值；已经开始的工作不会被追溯改变。
主库逻辑 sender 会等待列表中每个物理备库槽确认相关 WAL 后才发送解码变更。这保护 failover slot 连续性，但缺失、失效或停滞的槽会阻断逻辑复制与槽管理函数。
应把 synchronized_standby_slots 与 sync_replication_slots、primary_slot_name、max_replication_slots 一起监控和变更。先在对应角色与真实负载上验证，再按其 sighup context 选择会话修改、reload 或 restart；历史默认值并不等于当前有效值。
调优建议
Advice。 以下建议是工作负载起点，必须用真实测量验证。
| 场景 | 建议 |
|---|---|
| OLTP | 按主备拓扑、故障切换角色、复制槽/订阅数量与断连余量规划 synchronized_standby_slots；上线前验证主库写延迟、备库重放和磁盘保留的最坏情况。 |
| OLAP | 读备库与逻辑订阅常有长查询或大事务，应给重放/应用留明确上界，并监控延迟、worker 饱和、槽 restart_lsn 与冲突取消。 |
| 小规格 | 只配置真实需要的复制能力。少量节点也应设置有界超时与槽生命周期，不要用无限保留换取表面稳定。 |
Pigsty 取值
以下值来自固定 8 核、32 GiB、100 GiB SSD 夹具，并按 PG19 Beta 3 渲染当前 Pigsty 模板；这不表示 Pigsty 当前支持该历史或测试版本。
| 模板 | 有效值 | 与上游 boot 比较 | 源表达式 |
|---|---|---|---|
| OLTP | 未修改 | — | — |
| OLAP | 未修改 | — | — |
| CRIT | 未修改 | — | — |
| TINY | 未修改 | — | — |
Advice — 待人工复核。 当前 Pigsty 模板投影事实：OLTP: PG17–19 Beta 3 未修改；OLAP: PG17–19 Beta 3 未修改；CRIT: PG17–19 Beta 3 未修改；TINY: PG17–19 Beta 3 未修改。 未发现覆盖值，因此不推断 Pigsty 专属理由。
常见坑
- 列入缺失或失效槽，阻塞逻辑 sender。
- 混淆物理槽名与备库 application_name。
- 对应备库没有开启 sync_replication_slots。
- 在错误的主库、备库、发送端或订阅端角色上修改。
- 只看字节/时间配置，不监控真实复制延迟、槽位置与 worker 状态。
关联参数
sync_replication_slots · primary_slot_name · max_replication_slots · max_slot_wal_keep_size · synchronous_standby_names · vacuum_defer_cleanup_age
参考资料
22 - synchronous_standby_names
Fact — 官方简述译文：设置同步备库数量及候选备库名称列表。
身份
类型,- 上游 pg_settings 类型
Context,- 配置 reload 后生效
单位,- 原始单位
范围,- 最后在档版本的原始上下限
枚举值,- 非枚举类型记为 —
分类,- 上游分类
最后 boot 值,- empty string
生命周期
| Fact | 值 |
|---|---|
| 首次观测 | PG9.1 |
| 在档版本 | PG9.1–19 Beta 3 |
| 移除版本 | 否 |
| 引入提交 | a8a8a3e09652 — Efficient transaction-controlled synchronous replication. If a standby is broadcasting reply messages and we have named one or more standbys in synchronous_standby_names then allow users who set synchronous_replication to wait for commit, which then provides strict data integrity guarantees. Design avoids sending and receiving transaction state information so minimises bookkeeping overheads. We synchronize with the highest priority standby that is connected and ready to synchronize. Other standbys can be defined to takeover in case of standby failure. |
| 提交日期 | 2011-03-06 |
| Discussion | — |
默认值变迁
| 版本 | 原始 boot_val |
单位 | 人类可读值 |
|---|---|---|---|
| PG9.1–19 Beta 3 | "" |
— | empty string |
机制详解
设置同步备库数量及候选备库名称列表。重新加载配置即可应用新值；已经开始的工作不会被追溯改变。
它按备库 application_name 解析优先级 FIRST 或仲裁 ANY 语法，只定义可用确认者；每个事务等待什么由 synchronous_commit 决定，重复名称或通配符可能使实际选择出乎预期。
应把 synchronous_standby_names 与 synchronous_commit、wal_sender_timeout、max_wal_senders 一起监控和变更。先在对应角色与真实负载上验证，再按其 sighup context 选择会话修改、reload 或 restart；历史默认值并不等于当前有效值。
调优建议
Advice。 以下建议是工作负载起点，必须用真实测量验证。
| 场景 | 建议 |
|---|---|
| OLTP | 按主备拓扑、故障切换角色、复制槽/订阅数量与断连余量规划 synchronous_standby_names；上线前验证主库写延迟、备库重放和磁盘保留的最坏情况。 |
| OLAP | 读备库与逻辑订阅常有长查询或大事务，应给重放/应用留明确上界，并监控延迟、worker 饱和、槽 restart_lsn 与冲突取消。 |
| 小规格 | 只配置真实需要的复制能力。少量节点也应设置有界超时与槽生命周期，不要用无限保留换取表面稳定。 |
Pigsty 取值
以下值来自固定 8 核、32 GiB、100 GiB SSD 夹具，并按 PG19 Beta 3 渲染当前 Pigsty 模板；这不表示 Pigsty 当前支持该历史或测试版本。
| 模板 | 有效值 | 与上游 boot 比较 | 源表达式 |
|---|---|---|---|
| OLTP | 未修改 | — | — |
| OLAP | 未修改 | — | — |
| CRIT | 未修改 | — | — |
| TINY | 未修改 | — | — |
Advice — 待人工复核。 当前 Pigsty 模板投影事实：OLTP: PG9.1–19 Beta 3 未修改；OLAP: PG9.1–19 Beta 3 未修改；CRIT: PG9.1–19 Beta 3 未修改；TINY: PG9.1–19 Beta 3 未修改。 未发现覆盖值，因此不推断 Pigsty 专属理由。
常见坑
- 误以为只配置列表就能让每个事务同步。
- 重复 application_name 导致优先级选择不确定。
- ANY/FIRST 数量在计划维护期间无法满足。
- 在错误的主库、备库、发送端或订阅端角色上修改。
- 只看字节/时间配置，不监控真实复制延迟、槽位置与 worker 状态。
关联参数
synchronous_commit · wal_sender_timeout · max_wal_senders · application_name · synchronized_standby_slots · vacuum_defer_cleanup_age
参考资料
23 - track_commit_timestamp
Fact — 官方简述译文：记录事务提交时间。
身份
类型,- 上游 pg_settings 类型
Context,- 修改后需要重启数据库
单位,- 原始单位
范围,- 最后在档版本的原始上下限
枚举值,- 非枚举类型记为 —
分类,- 上游分类
最后 boot 值,- off
生命周期
| Fact | 值 |
|---|---|
| 首次观测 | PG9.5 |
| 在档版本 | PG9.5–19 Beta 3 |
| 移除版本 | 否 |
| 引入提交 | 73c986adde5d — Keep track of transaction commit timestamps |
| 提交日期 | 2014-12-03 |
| Discussion | — |
默认值变迁
| 版本 | 原始 boot_val |
单位 | 人类可读值 |
|---|---|---|---|
| PG9.5–19 Beta 3 | off |
— | off |
机制详解
记录事务提交时间。该值在服务器启动时固定，修改后必须重启。
它只在对应的发送端、主库、备库或订阅端角色上生效；级联复制与故障切换会改变服务器角色，因此相关容量和依赖应在所有候选节点一致规划。
应把 track_commit_timestamp 与 max_active_replication_origins、max_logical_replication_workers、max_replication_slots 一起监控和变更。先在对应角色与真实负载上验证，再按其 postmaster context 选择会话修改、reload 或 restart；历史默认值并不等于当前有效值。
调优建议
Advice。 以下建议是工作负载起点，必须用真实测量验证。
| 场景 | 建议 |
|---|---|
| OLTP | 按主备拓扑、故障切换角色、复制槽/订阅数量与断连余量规划 track_commit_timestamp；上线前验证主库写延迟、备库重放和磁盘保留的最坏情况。 |
| OLAP | 读备库与逻辑订阅常有长查询或大事务，应给重放/应用留明确上界，并监控延迟、worker 饱和、槽 restart_lsn 与冲突取消。 |
| 小规格 | 只配置真实需要的复制能力。少量节点也应设置有界超时与槽生命周期，不要用无限保留换取表面稳定。 |
Pigsty 取值
以下值来自固定 8 核、32 GiB、100 GiB SSD 夹具，并按 PG19 Beta 3 渲染当前 Pigsty 模板；这不表示 Pigsty 当前支持该历史或测试版本。
| 模板 | 有效值 | 与上游 boot 比较 | 源表达式 |
|---|---|---|---|
| OLTP | on |
不同于 boot 值 | 'on' |
| OLAP | on |
不同于 boot 值 | 'on' |
| CRIT | on |
不同于 boot 值 | 'on' |
| TINY | on |
不同于 boot 值 | 'on' |
Advice — 待人工复核。 当前 Pigsty 模板投影事实：OLTP: PG9.5–19 Beta 3 = on (dcs)；OLAP: PG9.5–19 Beta 3 = on (dcs)；CRIT: PG9.5–19 Beta 3 = on (dcs)；TINY: PG9.5–19 Beta 3 = on (dcs)。 建议（待人工复核）——编辑推断（待维护者人工复核）：该选择看起来意在为诊断和复制工作流提供提交时间元数据；发布前应结合当前 Pigsty 模板、硬件夹具和运维保证复核。
常见坑
- 在错误的主库、备库、发送端或订阅端角色上修改。
- 只看字节/时间配置，不监控真实复制延迟、槽位置与 worker 状态。
- 故障切换后新主库缺少与旧主库一致的容量或依赖。
- 用无限等待或无限 WAL 保留掩盖失效消费者。
关联参数
max_active_replication_origins · max_logical_replication_workers · max_replication_slots · idle_replication_slot_timeout · max_slot_wal_keep_size · max_wal_senders
参考资料
24 - vacuum_defer_cleanup_age
Fact — 官方简述译文：设置 VACUUM 与 HOT 清理要延后多少个事务。
身份
类型,- 上游 pg_settings 类型
Context,- 配置 reload 后生效
单位,- 原始单位
范围,- 最后在档版本的原始上下限
枚举值,- 非枚举类型记为 —
分类,- 上游分类
最后 boot 值,- 0
生命周期
| Fact | 值 |
|---|---|
| 首次观测 | PG9.0（研究下界） |
| 在档版本 | PG9.0–15 |
| 移除版本 | PG16 |
| 引入提交 | 不作断言：早于 PG9.0 研究边界 |
| 提交日期 | — |
| Discussion | — |
默认值变迁
| 版本 | 原始 boot_val |
单位 | 人类可读值 |
|---|---|---|---|
| PG9.0–15 | 0 |
— | 0 |
机制详解
设置 VACUUM 与 HOT 清理要延后多少个事务。该参数在 PG15 仍存在，并从 PG16 起不再被识别。PostgreSQL 16 移除了按事务数量延迟清理的机制；应根据真实需求组合 hot_standby_feedback、复制槽和有上界的备库冲突策略。
它曾让主库按固定事务数量延后删除近期死元组，是保护备库查询的粗略办法。它会保留膨胀却不能保证固定墙钟时间，并在 PostgreSQL 16 被移除。
升级前应联合检查 synchronized_standby_slots、synchronous_standby_names、hot_standby，从配置、ALTER SYSTEM、角色/数据库设置和自动化模板中删除旧名，并先验证替代机制再启动 PG16+。
调优建议
Advice。 以下建议是工作负载起点，必须用真实测量验证。
| 场景 | 建议 |
|---|---|
| OLTP | 不要在 PG16+ 调优或继续下发 vacuum_defer_cleanup_age。PostgreSQL 16 移除了按事务数量延迟清理的机制；应根据真实需求组合 hot_standby_feedback、复制槽和有上界的备库冲突策略。升级前扫描所有配置层并做业务回归。 |
| OLAP | 迁移方案与 OLTP 相同；另外在长批处理、备库或大对象/扩展工作流中验证新机制，不要假定删除旧开关会保留旧行为。 |
| 小规格 | 直接删除旧配置并采用受支持替代项；若没有真实兼容需求，不要用脚本伪造旧行为。 |
Pigsty 取值
以下值来自固定 8 核、32 GiB、100 GiB SSD 夹具，并按 PG15 渲染当前 Pigsty 模板；这不表示 Pigsty 当前支持该历史或测试版本。
| 模板 | 有效值 | 与上游 boot 比较 | 源表达式 |
|---|---|---|---|
| OLTP | 未修改 | — | — |
| OLAP | 未修改 | — | — |
| CRIT | 500000 |
不同于 boot 值 | 500000 |
| TINY | 未修改 | — | — |
Advice — 待人工复核。 当前 Pigsty 模板投影事实：OLTP: PG9.0–15 未修改；OLAP: PG9.0–15 未修改；CRIT: PG9.0–15 = 500000 (dcs)；TINY: PG9.0–15 未修改。 建议（待人工复核）——编辑推断（待维护者人工复核）：该选择看起来意在历史上通过延迟清理保护 CRIT 备库读，但这一策略现在必须迁移；发布前应结合当前 Pigsty 模板、硬件夹具和运维保证复核。
常见坑
- 在 PG16+ 配置中继续下发未知参数 vacuum_defer_cleanup_age。
- 只删除参数名，却未迁移依赖它的应用行为。
- 把历史默认值当作新版本替代机制的默认值。
- 遗漏 ALTER SYSTEM、角色/数据库设置或自动化模板中的旧条目。
关联参数
synchronized_standby_slots · synchronous_standby_names · hot_standby · hot_standby_feedback · idle_replication_slot_timeout · max_active_replication_origins
参考资料
25 - wal_keep_segments
Fact — 官方简述译文：设置为备库保留的 WAL 文件数量。
身份
类型,- 上游 pg_settings 类型
Context,- 配置 reload 后生效
单位,- 原始单位
范围,- 最后在档版本的原始上下限
枚举值,- 非枚举类型记为 —
分类,- 上游分类
最后 boot 值,- 0
生命周期
| Fact | 值 |
|---|---|
| 首次观测 | PG9.0（研究下界） |
| 在档版本 | PG9.0–12 |
| 移除版本 | PG13 |
| 引入提交 | 不作断言：早于 PG9.0 研究边界 |
| 提交日期 | — |
| Discussion | — |
默认值变迁
| 版本 | 原始 boot_val |
单位 | 人类可读值 |
|---|---|---|---|
| PG9.0–12 | 0 |
— | 0 |
机制详解
设置为备库保留的 WAL 文件数量。该参数在 PG12 仍存在，并从 PG13 起不再被识别。PostgreSQL 13 用 wal_keep_size 取代按段计数的接口；新参数用字节表示保留下限，不再隐含 WAL 段大小。
它至少为落后备库保留指定数量的旧 WAL 段，因此实际字节数取决于 wal_segment_size。它只是保留下限而非上限，也不能覆盖所有删除条件；PG13 改用 wal_keep_size。
升级前应联合检查 wal_keep_size、wal_segment_size、max_slot_wal_keep_size，从配置、ALTER SYSTEM、角色/数据库设置和自动化模板中删除旧名，并先验证替代机制再启动 PG13+。
调优建议
Advice。 以下建议是工作负载起点，必须用真实测量验证。
| 场景 | 建议 |
|---|---|
| OLTP | 不要在 PG13+ 调优或继续下发 wal_keep_segments。PostgreSQL 13 用 wal_keep_size 取代按段计数的接口；新参数用字节表示保留下限，不再隐含 WAL 段大小。升级前扫描所有配置层并做业务回归。 |
| OLAP | 迁移方案与 OLTP 相同；另外在长批处理、备库或大对象/扩展工作流中验证新机制，不要假定删除旧开关会保留旧行为。 |
| 小规格 | 直接删除旧配置并采用受支持替代项；若没有真实兼容需求，不要用脚本伪造旧行为。 |
Pigsty 取值
以下值来自固定 8 核、32 GiB、100 GiB SSD 夹具，并按 PG12 渲染当前 Pigsty 模板；这不表示 Pigsty 当前支持该历史或测试版本。
| 模板 | 有效值 | 与上游 boot 比较 | 源表达式 |
|---|---|---|---|
| OLTP | 未修改 | — | — |
| OLAP | 未修改 | — | — |
| CRIT | 未修改 | — | — |
| TINY | 未修改 | — | — |
Advice — 待人工复核。 当前 Pigsty 模板投影事实：OLTP: PG9.0–12 未修改；OLAP: PG9.0–12 未修改；CRIT: PG9.0–12 未修改；TINY: PG9.0–12 未修改。 未发现覆盖值，因此不推断 Pigsty 专属理由。
常见坑
- 没有乘以 wal_segment_size 就把旧整数直接复制到 wal_keep_size。
- 把保留数量误当上限而非下限。
- PG13+ 自动化中仍保留已移除名称。
- 在 PG13+ 配置中继续下发未知参数 wal_keep_segments。
- 只删除参数名，却未迁移依赖它的应用行为。
关联参数
wal_keep_size · wal_segment_size · max_slot_wal_keep_size · max_wal_size · primary_slot_name · idle_replication_slot_timeout
参考资料
26 - wal_keep_size
Fact — 官方简述译文：设置为备库保留的 WAL 文件大小。
身份
类型,- 上游 pg_settings 类型
Context,- 配置 reload 后生效
单位,- 原始单位
范围,- 最后在档版本的原始上下限
枚举值,- 非枚举类型记为 —
分类,- 上游分类
最后 boot 值,- 0 B
生命周期
| Fact | 值 |
|---|---|
| 首次观测 | PG13 |
| 在档版本 | PG13–19 Beta 3 |
| 移除版本 | 否 |
| 引入提交 | f5dff45962ec — Rename wal_keep_segments to wal_keep_size. |
| 提交日期 | 2020-07-20 |
| Discussion | 讨论 1 |
默认值变迁
| 版本 | 原始 boot_val |
单位 | 人类可读值 |
|---|---|---|---|
| PG13–19 Beta 3 | 0 |
MB |
0 B |
机制详解
发送端会在 pg_wal 中至少保留 wal_keep_size MB 的历史 WAL，使落后备库不会因旧段过早消失而中断流复制。如果落后距离超过现有文件，流连接会终止；若归档中存在缺失段，备库仍可从归档恢复。
它是保留下限，不是精确预留量，也不是上限。检查点恢复、归档、复制槽以及近期 WAL 用量估计都可能保留更多文件。值为 0 表示不专门为备库额外保留，并不表示 pg_wal 中没有旧 WAL。
复制槽依据各消费者确认位置精确保留 WAL，通常更可靠。wal_keep_size 仍可作为无槽备库或短暂重连的简单保险，但容量应按峰值 WAL 速率乘以预期中断窗口计算。
调优建议
Advice。 以下建议是工作负载起点，必须用真实测量验证。
| 场景 | 建议 |
|---|---|
| OLTP | 优先使用受监控的复制槽和经过验证的归档。确需非零下限时，按峰值 WAL 字节速率与容忍断连时间计算，再增加余量并监控复制延迟。 |
| OLAP | 短时间批量导入就可能突破静态保留量。必须跨越此类峰值的消费者应使用复制槽或归档，wal_keep_size 也应按峰值而非平均速率定值。 |
| 小规格 | 复制槽和归档恢复可靠时保持 0。否则选择不会在归档或复制槽事故叠加时耗尽磁盘的适度、有界值。 |
Pigsty 取值
以下值来自固定 8 核、32 GiB、100 GiB SSD 夹具，并按 PG19 Beta 3 渲染当前 Pigsty 模板；这不表示 Pigsty 当前支持该历史或测试版本。
| 模板 | 有效值 | 与上游 boot 比较 | 源表达式 |
|---|---|---|---|
| OLTP | 未修改 | — | — |
| OLAP | 未修改 | — | — |
| CRIT | 未修改 | — | — |
| TINY | 未修改 | — | — |
Advice — 待人工复核。 当前 Pigsty 模板投影事实：OLTP: PG13–19 Beta 3 未修改；OLAP: PG13–19 Beta 3 未修改；CRIT: PG13–19 Beta 3 未修改；TINY: PG13–19 Beta 3 未修改。 未发现覆盖值，因此不推断 Pigsty 专属理由。
常见坑
- 把 wal_keep_size 当作 pg_wal 使用量上限。
- 把 0 理解为“不保留 WAL”，而不是“不为备库额外保留”。
- 按平均 WAL 速率定值，在批任务峰值时失效。
- 认为备库超过保留窗口后仍保证可继续复制。
- 比较 PG12 与 PG13 时漏掉前身参数 wal_keep_segments。
关联参数
wal_keep_segments · max_replication_slots · max_slot_wal_keep_size · archive_mode · max_wal_size · primary_slot_name
参考资料
27 - wal_receiver_create_temp_slot
Fact — 官方简述译文：未配置永久槽时，设置 WAL receiver 是否创建临时复制槽。
身份
类型,- 上游 pg_settings 类型
Context,- 配置 reload 后生效
单位,- 原始单位
范围,- 最后在档版本的原始上下限
枚举值,- 非枚举类型记为 —
分类,- 上游分类
最后 boot 值,- off
生命周期
| Fact | 值 |
|---|---|
| 首次观测 | PG13 |
| 在档版本 | PG13–19 Beta 3 |
| 移除版本 | 否 |
| 引入提交 | 329730827848 — walreceiver uses a temporary replication slot by default |
| 提交日期 | 2020-01-14 |
| Discussion | 讨论 1 |
默认值变迁
| 版本 | 原始 boot_val |
单位 | 人类可读值 |
|---|---|---|---|
| PG13–19 Beta 3 | off |
— | off |
机制详解
未配置永久槽时，设置 WAL receiver 是否创建临时复制槽。重新加载配置即可应用新值；已经开始的工作不会被追溯改变。
primary_slot_name 为空时，receiver 可为连接生命周期创建上游临时槽。它能防止连接期间删除 WAL，但断连即消失，无法保证长时间中断后的追赶。
应把 wal_receiver_create_temp_slot 与 primary_slot_name、max_replication_slots、max_slot_wal_keep_size 一起监控和变更。先在对应角色与真实负载上验证，再按其 sighup context 选择会话修改、reload 或 restart；历史默认值并不等于当前有效值。
调优建议
Advice。 以下建议是工作负载起点，必须用真实测量验证。
| 场景 | 建议 |
|---|---|
| OLTP | 按主备拓扑、故障切换角色、复制槽/订阅数量与断连余量规划 wal_receiver_create_temp_slot；上线前验证主库写延迟、备库重放和磁盘保留的最坏情况。 |
| OLAP | 读备库与逻辑订阅常有长查询或大事务，应给重放/应用留明确上界，并监控延迟、worker 饱和、槽 restart_lsn 与冲突取消。 |
| 小规格 | 只配置真实需要的复制能力。少量节点也应设置有界超时与槽生命周期，不要用无限保留换取表面稳定。 |
Pigsty 取值
以下值来自固定 8 核、32 GiB、100 GiB SSD 夹具，并按 PG19 Beta 3 渲染当前 Pigsty 模板；这不表示 Pigsty 当前支持该历史或测试版本。
| 模板 | 有效值 | 与上游 boot 比较 | 源表达式 |
|---|---|---|---|
| OLTP | 未修改 | — | — |
| OLAP | 未修改 | — | — |
| CRIT | 未修改 | — | — |
| TINY | 未修改 | — | — |
Advice — 待人工复核。 当前 Pigsty 模板投影事实：OLTP: PG13–19 Beta 3 未修改；OLAP: PG13–19 Beta 3 未修改；CRIT: PG13–19 Beta 3 未修改；TINY: PG13–19 Beta 3 未修改。 未发现覆盖值，因此不推断 Pigsty 专属理由。
常见坑
- 在错误的主库、备库、发送端或订阅端角色上修改。
- 只看字节/时间配置，不监控真实复制延迟、槽位置与 worker 状态。
- 故障切换后新主库缺少与旧主库一致的容量或依赖。
- 用无限等待或无限 WAL 保留掩盖失效消费者。
关联参数
primary_slot_name · max_replication_slots · max_slot_wal_keep_size · wal_keep_size · hot_standby · hot_standby_feedback
参考资料
28 - wal_receiver_status_interval
Fact — 官方简述译文：设置 WAL receiver 向发送端报告状态的最大间隔。
身份
类型,- 上游 pg_settings 类型
Context,- 配置 reload 后生效
单位,- 原始单位
范围,- 最后在档版本的原始上下限
枚举值,- 非枚举类型记为 —
分类,- 上游分类
最后 boot 值,- 10 s
生命周期
| Fact | 值 |
|---|---|
| 首次观测 | PG9.1 |
| 在档版本 | PG9.1–19 Beta 3 |
| 移除版本 | 否 |
| 引入提交 | b186523fd97c — Send status updates back from standby server to master, indicating how far the standby has written, flushed, and applied the WAL. At the moment, this is for informational purposes only, the values are only shown in pg_stat_replication system view, but in the future they will also be needed for synchronous replication. |
| 提交日期 | 2011-02-10 |
| Discussion | — |
默认值变迁
| 版本 | 原始 boot_val |
单位 | 人类可读值 |
|---|---|---|---|
| PG9.1–19 Beta 3 | 10 |
s |
10 s |
机制详解
设置 WAL receiver 向发送端报告状态的最大间隔。重新加载配置即可应用新值；已经开始的工作不会被追溯改变。
它只在对应的发送端、主库、备库或订阅端角色上生效；级联复制与故障切换会改变服务器角色，因此相关容量和依赖应在所有候选节点一致规划。
应把 wal_receiver_status_interval 与 wal_receiver_timeout、wal_sender_timeout、primary_conninfo 一起监控和变更。先在对应角色与真实负载上验证，再按其 sighup context 选择会话修改、reload 或 restart；历史默认值并不等于当前有效值。
调优建议
Advice。 以下建议是工作负载起点，必须用真实测量验证。
| 场景 | 建议 |
|---|---|
| OLTP | 按主备拓扑、故障切换角色、复制槽/订阅数量与断连余量规划 wal_receiver_status_interval；上线前验证主库写延迟、备库重放和磁盘保留的最坏情况。 |
| OLAP | 读备库与逻辑订阅常有长查询或大事务，应给重放/应用留明确上界，并监控延迟、worker 饱和、槽 restart_lsn 与冲突取消。 |
| 小规格 | 只配置真实需要的复制能力。少量节点也应设置有界超时与槽生命周期，不要用无限保留换取表面稳定。 |
Pigsty 取值
以下值来自固定 8 核、32 GiB、100 GiB SSD 夹具，并按 PG19 Beta 3 渲染当前 Pigsty 模板；这不表示 Pigsty 当前支持该历史或测试版本。
| 模板 | 有效值 | 与上游 boot 比较 | 源表达式 |
|---|---|---|---|
| OLTP | 1s |
不同于 boot 值 | 1s |
| OLAP | 1s |
不同于 boot 值 | 1s |
| CRIT | 1s |
不同于 boot 值 | 1s |
| TINY | 1s |
不同于 boot 值 | 1s |
Advice — 待人工复核。 当前 Pigsty 模板投影事实：OLTP: PG9.1–19 Beta 3 = 1s (dcs)；OLAP: PG9.1–19 Beta 3 = 1s (dcs)；CRIT: PG9.1–19 Beta 3 = 1s (dcs)；TINY: PG9.1–19 Beta 3 = 1s (dcs)。 建议（待人工复核）——编辑推断（待维护者人工复核）：该选择看起来意在向发送端与监控提供更新鲜的重放/刷写反馈；发布前应结合当前 Pigsty 模板、硬件夹具和运维保证复核。
常见坑
- 在错误的主库、备库、发送端或订阅端角色上修改。
- 只看字节/时间配置，不监控真实复制延迟、槽位置与 worker 状态。
- 故障切换后新主库缺少与旧主库一致的容量或依赖。
- 用无限等待或无限 WAL 保留掩盖失效消费者。
关联参数
wal_receiver_timeout · wal_sender_timeout · primary_conninfo · hot_standby_feedback · hot_standby · max_standby_archive_delay
参考资料
29 - wal_receiver_timeout
Fact — 官方简述译文：设置等待发送端数据的最长时间。
身份
类型,- 上游 pg_settings 类型
Context,- 普通用户可在运行时修改
单位,- 原始单位
范围,- 最后在档版本的原始上下限
枚举值,- 非枚举类型记为 —
分类,- 上游分类
最后 boot 值,- 1 min
生命周期
| Fact | 值 |
|---|---|
| 首次观测 | PG9.3 |
| 在档版本 | PG9.3–19 Beta 3 |
| 移除版本 | 否 |
| 引入提交 | 6f60fdd7015b — Improve replication connection timeouts. |
| 提交日期 | 2012-10-11 |
| Discussion | — |
默认值变迁
| 版本 | 原始 boot_val |
单位 | 人类可读值 |
|---|---|---|---|
| PG9.3–19 Beta 3 | 60000 |
ms |
1 min |
机制详解
设置等待发送端数据的最长时间。重新加载配置即可应用新值；已经开始的工作不会被追溯改变。
它只在对应的发送端、主库、备库或订阅端角色上生效；级联复制与故障切换会改变服务器角色，因此相关容量和依赖应在所有候选节点一致规划。
应把 wal_receiver_timeout 与 primary_conninfo、primary_slot_name、restore_command 一起监控和变更。先在对应角色与真实负载上验证，再按其 sighup context 选择会话修改、reload 或 restart；历史默认值并不等于当前有效值。
调优建议
Advice。 以下建议是工作负载起点，必须用真实测量验证。
| 场景 | 建议 |
|---|---|
| OLTP | 按主备拓扑、故障切换角色、复制槽/订阅数量与断连余量规划 wal_receiver_timeout；上线前验证主库写延迟、备库重放和磁盘保留的最坏情况。 |
| OLAP | 读备库与逻辑订阅常有长查询或大事务，应给重放/应用留明确上界，并监控延迟、worker 饱和、槽 restart_lsn 与冲突取消。 |
| 小规格 | 只配置真实需要的复制能力。少量节点也应设置有界超时与槽生命周期，不要用无限保留换取表面稳定。 |
Pigsty 取值
以下值来自固定 8 核、32 GiB、100 GiB SSD 夹具，并按 PG19 Beta 3 渲染当前 Pigsty 模板；这不表示 Pigsty 当前支持该历史或测试版本。
| 模板 | 有效值 | 与上游 boot 比较 | 源表达式 |
|---|---|---|---|
| OLTP | 60s |
等于 boot 值 | 60s |
| OLAP | 60s |
等于 boot 值 | 60s |
| CRIT | 60s |
等于 boot 值 | 60s |
| TINY | 60s |
等于 boot 值 | 60s |
Advice — 待人工复核。 当前 Pigsty 模板投影事实：OLTP: PG9.3–19 Beta 3 = 60s (dcs)；OLAP: PG9.3–19 Beta 3 = 60s (dcs)；CRIT: PG9.3–19 Beta 3 = 60s (dcs)；TINY: PG9.3–19 Beta 3 = 60s (dcs)。 建议（待人工复核）——编辑推断（待维护者人工复核）：该选择看起来意在显式采用一分钟的 receiver 故障检测窗口；发布前应结合当前 Pigsty 模板、硬件夹具和运维保证复核。
常见坑
- 在错误的主库、备库、发送端或订阅端角色上修改。
- 只看字节/时间配置，不监控真实复制延迟、槽位置与 worker 状态。
- 故障切换后新主库缺少与旧主库一致的容量或依赖。
- 用无限等待或无限 WAL 保留掩盖失效消费者。
关联参数
primary_conninfo · primary_slot_name · restore_command · wal_retrieve_retry_interval · hot_standby · wal_receiver_status_interval
参考资料
30 - wal_retrieve_retry_interval
Fact — 官方简述译文：设置 WAL 获取失败后的重试等待时间。
身份
类型,- 上游 pg_settings 类型
Context,- 配置 reload 后生效
单位,- 原始单位
范围,- 最后在档版本的原始上下限
枚举值,- 非枚举类型记为 —
分类,- 上游分类
最后 boot 值,- 5 s
生命周期
| Fact | 值 |
|---|---|
| 首次观测 | PG9.5 |
| 在档版本 | PG9.5–19 Beta 3 |
| 移除版本 | 否 |
| 引入提交 | 5d2b45e3f78a — Add GUC to control the time to wait before retrieving WAL after failed attempt. |
| 提交日期 | 2015-02-23 |
| Discussion | — |
默认值变迁
| 版本 | 原始 boot_val |
单位 | 人类可读值 |
|---|---|---|---|
| PG9.5–19 Beta 3 | 5000 |
ms |
5 s |
机制详解
设置 WAL 获取失败后的重试等待时间。重新加载配置即可应用新值；已经开始的工作不会被追溯改变。
它只在对应的发送端、主库、备库或订阅端角色上生效；级联复制与故障切换会改变服务器角色，因此相关容量和依赖应在所有候选节点一致规划。
应把 wal_retrieve_retry_interval 与 primary_conninfo、primary_slot_name、restore_command 一起监控和变更。先在对应角色与真实负载上验证，再按其 sighup context 选择会话修改、reload 或 restart；历史默认值并不等于当前有效值。
调优建议
Advice。 以下建议是工作负载起点，必须用真实测量验证。
| 场景 | 建议 |
|---|---|
| OLTP | 按主备拓扑、故障切换角色、复制槽/订阅数量与断连余量规划 wal_retrieve_retry_interval；上线前验证主库写延迟、备库重放和磁盘保留的最坏情况。 |
| OLAP | 读备库与逻辑订阅常有长查询或大事务，应给重放/应用留明确上界，并监控延迟、worker 饱和、槽 restart_lsn 与冲突取消。 |
| 小规格 | 只配置真实需要的复制能力。少量节点也应设置有界超时与槽生命周期，不要用无限保留换取表面稳定。 |
Pigsty 取值
以下值来自固定 8 核、32 GiB、100 GiB SSD 夹具，并按 PG19 Beta 3 渲染当前 Pigsty 模板；这不表示 Pigsty 当前支持该历史或测试版本。
| 模板 | 有效值 | 与上游 boot 比较 | 源表达式 |
|---|---|---|---|
| OLTP | 未修改 | — | — |
| OLAP | 未修改 | — | — |
| CRIT | 未修改 | — | — |
| TINY | 未修改 | — | — |
Advice — 待人工复核。 当前 Pigsty 模板投影事实：OLTP: PG9.5–19 Beta 3 未修改；OLAP: PG9.5–19 Beta 3 未修改；CRIT: PG9.5–19 Beta 3 未修改；TINY: PG9.5–19 Beta 3 未修改。 未发现覆盖值，因此不推断 Pigsty 专属理由。
常见坑
- 在错误的主库、备库、发送端或订阅端角色上修改。
- 只看字节/时间配置，不监控真实复制延迟、槽位置与 worker 状态。
- 故障切换后新主库缺少与旧主库一致的容量或依赖。
- 用无限等待或无限 WAL 保留掩盖失效消费者。
关联参数
primary_conninfo · primary_slot_name · restore_command · wal_receiver_timeout · hot_standby · hot_standby_feedback
参考资料
31 - wal_sender_delay
Fact — 官方简述译文：设置 WAL sender 两次复制动作之间的休眠时间。
身份
类型,- 上游 pg_settings 类型
Context,- 配置 reload 后生效
单位,- 原始单位
范围,- 最后在档版本的原始上下限
枚举值,- 非枚举类型记为 —
分类,- 上游分类
最后 boot 值,- 1 s
生命周期
| Fact | 值 |
|---|---|
| 首次观测 | PG9.0（研究下界） |
| 在档版本 | PG9.0–9.1 |
| 移除版本 | PG9.2 |
| 引入提交 | 不作断言：早于 PG9.0 研究边界 |
| 提交日期 | — |
| Discussion | — |
默认值变迁
| 版本 | 原始 boot_val |
单位 | 人类可读值 |
|---|---|---|---|
| PG9.0 | 200 |
ms |
200 ms |
| PG9.1 | 1000 |
ms |
1 s |
机制详解
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，并在修改前后对比真实负载、日志和资源指标。
调优建议
Advice。 以下建议是工作负载起点，必须用真实测量验证。
| 场景 | 建议 |
|---|---|
| OLTP | 不要把这个已退出的名称加入现代 OLTP 配置。应把原意迁移到文档给出的后继参数，在连接与写并发下验证，并清理仍会输出旧名称的自动化。 |
| OLAP | 升级分析型环境前应盘点所有生成配置，把旧控制映射到后继项，并比较执行计划、吞吐、WAL 或日志行为；不能假设旧数值可直接搬用。 |
| 小规格 | 记录旧覆盖存在的原因后将其删除。小节点应先采用后继参数默认值，实测后再调整；未知的启动参数可能直接阻止服务器启动。 |
Pigsty 取值
以下值来自固定 8 核、32 GiB、100 GiB SSD 夹具，并按 PG9.1 渲染当前 Pigsty 模板；这不表示 Pigsty 当前支持该历史或测试版本。
| 模板 | 有效值 | 与上游 boot 比较 | 源表达式 |
|---|---|---|---|
| OLTP | 未修改 | — | — |
| OLAP | 未修改 | — | — |
| CRIT | 未修改 | — | — |
| TINY | 未修改 | — | — |
Advice — 待人工复核。 当前 Pigsty 模板投影事实：OLTP: PG9.0–9.1 未修改；OLAP: PG9.0–9.1 未修改；CRIT: PG9.0–9.1 未修改；TINY: PG9.0–9.1 未修改。 未发现覆盖值，因此不推断 Pigsty 专属理由。
常见坑
- 把 wal_sender_delay 的实测 boot_val 当成初始化后或托管集群当前有效值的证明。
- 忽略 pg_settings 报告的 sighup context，误以为修改会立即生效。
- 孤立修改该参数，没有检查关联上限、可观测性和回滚路径。
- 把已移除名称复制到现代 postgresql.conf，而没有迁移到文档给出的后继参数。
关联参数
wal_sender_timeout · wal_receiver_status_interval · wal_receiver_timeout · max_wal_senders
参考资料
32 - wal_sender_shutdown_timeout
Fact — 官方简述译文：设置关机时等待 WAL 全部复制到接收端的最长时间。
身份
类型,- 上游 pg_settings 类型
Context,- 普通用户可在运行时修改
单位,- 原始单位
范围,- 最后在档版本的原始上下限
枚举值,- 非枚举类型记为 —
分类,- 上游分类
最后 boot 值,- -1 ms
生命周期
| Fact | 值 |
|---|---|
| 首次观测 | PG19 Beta 3 |
| 在档版本 | PG19 Beta 3 |
| 移除版本 | 否 |
| 引入提交 | a8f45dee9176 — Add wal_sender_shutdown_timeout GUC to limit shutdown wait for replication |
| 提交日期 | 2026-04-06 |
| Discussion | 讨论 1 |
默认值变迁
| 版本 | 原始 boot_val |
单位 | 人类可读值 |
|---|---|---|---|
| PG19 Beta 3 | -1 |
ms |
-1 ms |
机制详解
wal_sender_shutdown_timeout：设置关机时等待 WAL 全部复制到接收端的最长时间。它可以按会话修改，便于在不影响全部负载的前提下比较计划或行为。 本站在 PG19 Beta 3 实测到它；boot_val 是编译或初始化基线，并不能证明某个运行集群的当前有效值。
关机时 WAL sender 通常等待未发送 WAL 到达接收端。默认 -1 无限等待，0 立即停止，正值限定等待时间但可能让两端暂时不一致；连接选项可为物理与逻辑复制链路设置不同策略。
应与 wal_sender_timeout、wal_receiver_timeout、synchronous_commit、synchronous_standby_names 一起理解。请在目标服务器检查 SHOW 与 pg_settings，确认 source 和 pending_restart，并在修改前后对比真实负载、日志和资源指标。
调优建议
Advice。 以下建议是工作负载起点，必须用真实测量验证。
| 场景 | 建议 |
|---|---|
| OLTP | 设定边界前要模拟正常故障转移与最坏复制延迟，并观察 sender 状态、保留 WAL、关机耗时和接收端追赶；为监控与计划切换保留足够容量。 |
| OLAP | 应计入大事务、批量装载、慢 apply 与远距离链路。较短超时虽能加快关机，却可能把恢复工作和不一致风险转移到下次启动。 |
| 小规格 | 限制槽和 sender 数量，监控 pg_wal 磁盘占用，并明确超时语义；分别在接收端健康与不可用时测试关机和重启。 |
Pigsty 取值
以下值来自固定 8 核、32 GiB、100 GiB SSD 夹具，并按 PG19 Beta 3 渲染当前 Pigsty 模板；这不表示 Pigsty 当前支持该历史或测试版本。
| 模板 | 有效值 | 与上游 boot 比较 | 源表达式 |
|---|---|---|---|
| OLTP | 未修改 | — | — |
| OLAP | 未修改 | — | — |
| CRIT | 未修改 | — | — |
| TINY | 未修改 | — | — |
Advice — 待人工复核。 当前 Pigsty 模板投影事实：OLTP: PG19 Beta 3 未修改；OLAP: PG19 Beta 3 未修改；CRIT: PG19 Beta 3 未修改；TINY: PG19 Beta 3 未修改。 未发现覆盖值，因此不推断 Pigsty 专属理由。
常见坑
- 把 wal_sender_shutdown_timeout 的实测 boot_val 当成初始化后或托管集群当前有效值的证明。
- 忽略 pg_settings 报告的 user context，误以为修改会立即生效。
- 孤立修改该参数，没有检查关联上限、可观测性和回滚路径。
- 在生产中依赖测试版行为，却没有在 PostgreSQL 19 正式版发布后重新验证。
关联参数
wal_sender_timeout · wal_receiver_timeout · synchronous_commit · synchronous_standby_names · max_wal_senders
参考资料
33 - wal_sender_timeout
Fact — 官方简述译文：设置等待 WAL 复制活动的最长时间。
身份
类型,- 上游 pg_settings 类型
Context,- 普通用户可在运行时修改
单位,- 原始单位
范围,- 最后在档版本的原始上下限
枚举值,- 非枚举类型记为 —
分类,- 上游分类
最后 boot 值,- 1 min
生命周期
| Fact | 值 |
|---|---|
| 首次观测 | PG9.3 |
| 在档版本 | PG9.3–19 Beta 3 |
| 移除版本 | 否 |
| 引入提交 | 6f60fdd7015b — Improve replication connection timeouts. |
| 提交日期 | 2012-10-11 |
| Discussion | — |
默认值变迁
| 版本 | 原始 boot_val |
单位 | 人类可读值 |
|---|---|---|---|
| PG9.3–19 Beta 3 | 60000 |
ms |
1 min |
机制详解
设置等待 WAL 复制活动的最长时间。它可在会话级修改，因此不同会话可能采用不同的行为。
它只在对应的发送端、主库、备库或订阅端角色上生效；级联复制与故障切换会改变服务器角色，因此相关容量和依赖应在所有候选节点一致规划。
应把 wal_sender_timeout 与 max_wal_senders、max_replication_slots、wal_level 一起监控和变更。先在对应角色与真实负载上验证，再按其 user context 选择会话修改、reload 或 restart；历史默认值并不等于当前有效值。
调优建议
Advice。 以下建议是工作负载起点，必须用真实测量验证。
| 场景 | 建议 |
|---|---|
| OLTP | 按主备拓扑、故障切换角色、复制槽/订阅数量与断连余量规划 wal_sender_timeout；上线前验证主库写延迟、备库重放和磁盘保留的最坏情况。 |
| OLAP | 读备库与逻辑订阅常有长查询或大事务，应给重放/应用留明确上界，并监控延迟、worker 饱和、槽 restart_lsn 与冲突取消。 |
| 小规格 | 只配置真实需要的复制能力。少量节点也应设置有界超时与槽生命周期，不要用无限保留换取表面稳定。 |
Pigsty 取值
以下值来自固定 8 核、32 GiB、100 GiB SSD 夹具，并按 PG19 Beta 3 渲染当前 Pigsty 模板；这不表示 Pigsty 当前支持该历史或测试版本。
| 模板 | 有效值 | 与上游 boot 比较 | 源表达式 |
|---|---|---|---|
| OLTP | 未修改 | — | — |
| OLAP | 未修改 | — | — |
| CRIT | 未修改 | — | — |
| TINY | 未修改 | — | — |
Advice — 待人工复核。 当前 Pigsty 模板投影事实：OLTP: PG9.3–19 Beta 3 未修改；OLAP: PG9.3–19 Beta 3 未修改；CRIT: PG9.3–19 Beta 3 未修改；TINY: PG9.3–19 Beta 3 未修改。 未发现覆盖值，因此不推断 Pigsty 专属理由。
常见坑
- 在错误的主库、备库、发送端或订阅端角色上修改。
- 只看字节/时间配置，不监控真实复制延迟、槽位置与 worker 状态。
- 故障切换后新主库缺少与旧主库一致的容量或依赖。
- 用无限等待或无限 WAL 保留掩盖失效消费者。
关联参数
max_wal_senders · max_replication_slots · wal_level · primary_conninfo · max_slot_wal_keep_size · wal_receiver_status_interval