SQL PostgreSQL 的 logical_decoding_work_mem 的逻辑解码内存预算

logical_decoding_work_mem是postmaster级会话参数，修改后必须重启服务才生效，pg_reload_conf()无效；需确认wal_level=logical且max_replication_slots足够，监控restart_lsn和confirmed_flush_lsn判断是否真生效。

logical_decoding_work_mem 设置后没生效？检查配置加载方式

postgresql 的 logical_decoding_work_mem 是会话级参数，不是全局动态参数——改完 postgresql.conf 或用 ALTER SYSTEM 设置后，必须重启服务才生效，pg_reload_conf() 不管用。

常见错误现象：

• 修改配置后执行 SHOW logical_decoding_work_mem; 仍返回默认值（64MB）
• 逻辑复制或解码插件（如 pgoutput、wal2json）内存占用没变化

使用场景：

• 解析大事务（如单条 UPDATE 影响百万行）时频繁触发 Error: out of memory
• 使用 pg_logical_slot_get_changes() 拉取大量变更时卡住或超时

实操建议：

• select name, setting, context FROM pg_settings WHERE name = 'logical_decoding_work_mem'; 看 context 字段，确认是 postmaster 级别
• 修改后必须 pg_ctl restart 或系统级重启，不能只 reload
• 生产环境建议先在测试库验证重启影响，避免 slot 暂停导致 WAL 积压

设多大才合适？看 slot 类型和变更密度

这个参数控制每个逻辑解码会话能用的最大内存，但不是越大越好：过大会挤占 shared_buffers 和 WAL 缓冲区，反而拖慢整体写入；过小会导致频繁落盘（spill to disk），解码变慢甚至失败。

性能影响关键点：

• 对 pgoutput（物理复制协议封装的逻辑复制）影响最直接
• 对 wal2json、decoderbufs 等第三方插件，实际内存消耗还取决于消息序列化开销

推荐设置原则：

• 默认 64MB 足够应付单事务 ≤ 10 万行变更
• 高频小事务（如每秒数百条 INSERT）可保持默认，重点调 max_replication_slots 和 wal_keep_size
• 批量导入后立即解码（如 etl 场景），临时调高到 256–512MB，但需监控 pg_stat_replication 中 pg_wal_lsn_diff 是否持续增长

和 work_mem 混用会冲突吗？完全独立，但别漏掉 wal_level

logical_decoding_work_mem 和 work_mem 无任何共享逻辑——前者专供 WAL 解析器构建事务快照和变更缓冲，后者用于排序、哈希等查询操作。

容易踩的坑：

• 改了 logical_decoding_work_mem 却忘了 wal_level = logical，结果 slot 创建直接报错：ERROR: cannot create logical replication slot without wal_level >= logical
• 在 hot_standby = on 的从库上尝试创建逻辑 slot，报错：ERROR: logical decoding cannot be used on a standby server

必须同步检查：

• SHOW wal_level; 必须为 logical（不能是 replica）
• SHOW max_replication_slots; ≥ 当前需要的 slot 数量
• SHOW track_commit_timestamp; 若解码需精确提交顺序，需开启（但会带来额外 WAL 开销）

监控是否真起作用？盯紧 pg_stat_replication 和 pg_replication_slots

光看参数值没用，得观察 slot 实际行为。内存不足时不会报 “memory too small”，而是表现为：

• pg_replication_slots 中 restart_lsn 滞后严重，confirmed_flush_lsn 停滞
• pg_stat_replication 的 state 长期卡在 streaming，但 sent_lsn 和 write_lsn 差距拉大
• 日志里反复出现：WARNING: logical decoding worker exited due to error: out of memory

实操建议：

• 定期查：SELECT slot_name, plugin, restart_lsn, confirmed_flush_lsn, active FROM pg_replication_slots;
• 如果 active = false 且 confirmed_flush_lsn 不动，大概率是解码进程被 OOM kill
• 结合 pg_stat_database_conflicts 看是否有 confl_bufferpin 上升——说明 WAL 解析和 backend 内存竞争激烈

逻辑解码内存预算真正难的不是设数字，而是得把 slot 生命周期、WAL 生成节奏、下游消费能力串起来看；单独调一个参数，往往掩盖了 slot 滞后或消费者卡顿的真实问题。