PostgreSQL 11复制槽出现out of memory error，如何限制walsenders内存占用？

PostgreSQL 13新增的logical_decoding_work_mem参数可以直接控制逻辑解码阶段的内存占用，但该特性无法向下兼容到11版本，可通过以下方案限制walsenders内存，避免复制槽相关的OOM错误：

1. 调整数据库内核参数约束内存使用 #

• 控制walsender并发上限：调整max_wal_senders参数，该参数限制了同时运行的walsender进程总数，每一个激活的逻辑复制槽通常对应一个walsender进程，根据服务器内存容量下调该参数值，可以直接降低walsender进程组的总内存消耗，修改后需要重启实例生效。
• 间接限制单进程内存峰值：逻辑解码过程中walsender会使用work_mem分配排序、哈希操作的内存，适当降低work_mem的全局配置值（建议不超过服务器总内存的1/200），可以避免单个walsender处理大事务时占用过多内存。
• 自动清理异常walsender进程：配置wal_sender_timeout参数，超时自动断开长时间无响应、卡住的walsender进程，避免异常进程持续占用内存不释放，可根据业务延迟容忍度设置为60s~600s，修改后执行pg_reload_conf()即可生效。

2. 优化业务与复制配置降低内存开销 #

• 拆分超大事务：逻辑解码需要在内存中缓存完整事务的所有变更信息，主库的超大事务是触发walsender OOM的核心诱因，建议将单事务变更行数超过10万的超大事务拆分为多个小事务分批提交，从根源上降低walsender的内存峰值。
• 定期清理无用复制槽：未被消费的逻辑复制槽会持续积压WAL日志，对应walsender激活后需要一次性处理大量历史变更，极易触发OOM。可以通过SELECT * FROM pg_replication_slots;查询复制槽状态，及时删除active字段为f且不再使用的冗余复制槽。

3. 操作系统层面兜底防护 #

• 通过cgroup对walsender进程组设置硬性内存上限，避免walsender占用过多内存导致整个数据库实例崩溃。
• 调整OOM Killer优先级，给postmaster主进程设置更高的OOM规避权重，确保异常高内存占用的walsender进程被优先杀死，保护主库业务正常运行。

可选方案：如果业务允许版本升级，建议升级到PostgreSQL 13及以上版本，可通过内置的logical_decoding_work_mem参数更精准地管控逻辑解码内存，从内核层面解决该问题。

内容的提问来源于stack exchange，提问作者user2930137