logical_decoding_work_mem需按峰值变更行数×128b估算并加20%余量，如200万行建议256mb；它独立作用于每个decoding worker，与work_mem、maintenance_work_mem互不干扰。
logical_decoding_work_mem 设置多大才不爆 OOM？
PostgreSQL 的 logical_decoding_work_mem 不是“越大越好”，而是要卡在 WAL 解析吞吐与内存安全的平衡点上。设太高，单个逻辑复制槽（replication slot）可能吃光 shared_buffers 外内存，触发 out of memory；设太低，解码器反复 flush 中间状态，CPU 和 I/O 反而飙升，延迟拉高。
- 默认值
64MB对小事务量库够用，但只要单事务修改行数 > 50 万，或批量 UPDATE/DELETE 频繁，就大概率触发ERROR: out of memory或日志里反复出现logical decoding worker restarting - 建议起步值按「峰值变更行数 × 每行平均开销 128B」粗估，例如单事务改 200 万行 → 至少预留
256MB；再加 20% 余量防碎片 - 不能全局无脑调高：该参数是 *每个* decoding worker 独立分配的，一个 slot 启多个 worker（如并行 apply 场景）会乘倍消耗
和 work_mem、maintenance_work_mem 有什么区别？
这三个参数名字像，但作用域和触发时机完全不同：work_mem 控制排序、哈希等 SQL 执行内存；maintenance_work_mem 用于 VACUUM、CREATE INDEX；而 logical_decoding_work_mem 只服务于 WAL 解析阶段——即从磁盘读出 WAL 记录后，在内存里反序列化成 logical change（INSERT/UPDATE/DELETE 元组），再打包发给客户端（如 Debezium、pg_recvlogical）。
- 它们互不共享，也不会叠加生效；调高
logical_decoding_work_mem对查询性能无直接影响 - 但如果复制下游消费慢，WAL 积压会导致
pg_wal目录暴涨，此时maintenance_work_mem不足会让后续 VACUUM 失败，间接拖垮 decoding —— 所以得一起盯 - 线上曾见把
logical_decoding_work_mem设到2GB，结果单个 slot 占用 RSS 超 3.5GB，OS 开始杀进程；最后压回512MB+ 增加下游并发消费线程才稳住
怎么验证当前值是否合理？
别只看 SHOW logical_decoding_work_mem，关键看运行时行为。PostgreSQL 本身不暴露 decoding 内存实时用量，但可通过组合指标交叉判断：
- 查日志：grep
"logical decoding worker restarting"或"out of memory"—— 出现就是硬性超限，必须降负载或提配额 - 监控
pg_replication_slots视图里的restart_lsn和confirmed_flush_lsn差距：持续拉大（> 100MB WAL）说明 decoding 卡住，可能因内存不足频繁重试 - 用
pg_stat_activity看 decoding 进程状态：若长期处于active但backend_start时间很新（几分钟内反复重启），基本可断定内存抖动
PG 14+ 并行 decoding 下的特殊注意点
PG 14 引入并行 logical decoding（通过 max_logical_replication_workers 和 slot 级参数控制），这时 logical_decoding_work_mem 是 *每个 worker* 的上限，不是总和。容易误判成“我只开了 2 个 worker，设 1GB 应该没问题”，实际是 2 × 1GB = 2GB 瞬时需求。
- 并行模式下，worker 之间不共享 decode 缓冲区，各自独立解析 WAL segment 片段，内存无法复用
- 如果下游消费能力弱，多个 worker 会同时堆积未发送变更，总内存占用 = worker 数 ×
logical_decoding_work_mem× （平均积压程度） - 实测发现：PG 15 在高并发写入下，即使
logical_decoding_work_mem=256MB，开启 4 个 worker 后 RSS 峰值仍突破 1.2GB；最终改成 2 worker +384MB更稳
调优这事没法一锤定音，得盯着 pg_replication_slots、系统 RSS、错误日志三块数据来回比对；尤其要注意 PG 小版本升级后 decoding 内存模型的细微变化——比如 PG 15.4 修复了一个 buffer 未及时释放的 bug，同样配置下内存占用直接降了 30%。
