Pgpool-II 的 CVE-2026-92868 是本月 PostgreSQL 生态最要紧的一条。借这个机会聊一下 ERP 数据库层的补丁管理。
一个常见的管理盲区
很多企业的补丁清单里有操作系统、有数据库、有中间件，但没有连接池。
原因是连接池通常被当成「配置好就不用管的基础设施」，装完之后几年不动，也没有责任人。
为什么这对 ERP 尤其危险
ERP 的数据库是所有业务数据的汇聚点。连接池又在应用和数据库之间，是必经之路。
如果池层存在认证绕过，那么数据库侧的账号权限、审计日志都可能被绕过。你以为生效的控制，实际形同虚设。
该做什么
第一，清点所有连接池实例，记录确切版本号。这一步常常做不完整，因为实例分散在多个环境。
第二，升级到对应版本：Pgpool-II 选 4.7.3 / 4.6.8 / 4.5.13 / 4.4.18 / 4.3.21 中对应你版本线的那个。
第三，如果在池层终止客户端证书，把这条当紧急项处理。
第四，检查池层是否能从不可信网络访问。能的话立即收紧。
顺便说说性能侧的收益
YugabyteDB Aeon 本月把内置 YSQL 连接池转 GA（v2026.1+）。这提示了一个简化方向：如果数据库本身提供连接池，可以省掉外部那一层。
少一层就少一个故障域、少一份运维责任、少一处补丁义务。
ERP 数据库运维的三条经验
第一，备份要验证可恢复。很多企业的备份一直在跑，但从没验证过恢复。备份没验过等于没有。
第二，慢查询要定期分析。ERP 的慢查询往往集中在月结、报表、大批量单据处理这几个场景，优化收益明显。
第三，索引要随业务演进调整。三年前建的索引，未必适配现在的查询模式。
顺带提一个工具
Dasha 1.8 是开源的 Postgres 集群看板，新增了基于 pg_stat_statements 的 B-tree 索引建议，每条都附带可以直接执行的 CREATE INDEX CONCURRENTLY 语句。做巡检的话可以看看，比手工分析 pg_stat_statements 输出效率高不少。
一句话
ERP 系统的安全水位，取决于最薄弱的那一环。连接池这种「看不见的组件」，往往就是那一环。
本文由奇幻维度内容助手整理发布，欢迎在评论区交流你的看法。