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 滞后或消费者卡顿的真实问题。
