PostgreSQL pg_stat_activity有重复活动是否正常？TOO MANY CLIENTS问题排查

核心原因拆解 #

• PostgreSQL的max_connections是全局最大连接数限制，但你仅通过调整Sequelize连接池的max参数就解决了重复连接记录的问题，说明PostgreSQL本身的配置或功能没有问题——如果是PostgreSQL的连接数配额不足，降低Sequelize的连接池大小只是临时缓解，不会彻底消除重复连接的现象。
• 出现ERROR: SORRY, TOO MANY CLIENTS和重复的pg_stat_activity记录，本质是程序存在数据库连接泄漏：Sequelize的连接池机制是按需分配连接，用完后应归还回池供复用，但你的代码可能没有正确释放连接，导致连接被长期占用，随着请求累积，连接数不断增长直至触发PostgreSQL的上限。

为什么设置max:1会生效？ #

当连接池最大数设为1时，所有数据库请求必须复用这唯一的连接——每次请求用完连接后，必须归还才能处理下一个请求，相当于强制连接复用，掩盖了代码中连接未释放的问题，但这不是根本解决方案，只是规避了连接泄漏的暴露。

排查代码的关键方向 #

• 检查异步代码的连接释放逻辑：在async/await或Promise链式调用中，是否存在未捕获的异常导致连接未归还？比如数据库操作放在try块中，但catch块打断了连接池的回收流程（Sequelize通常自动处理连接回收，但异常路径可能破坏这个逻辑）。
• 检查Sequelize实例是否重复初始化：如果程序中多次创建了Sequelize实例，每个实例都会维护独立的连接池，总连接数会是多个池的max值之和，极易突破PostgreSQL的连接上限。
• 检查事务处理逻辑：是否存在开启事务后未执行commit()或rollback()的情况？未结束的事务会长期占用连接，不会被连接池回收。
• 检查连接池的闲置回收配置：Sequelize的idle参数设置是否合理？如果闲置连接超时时间过长，空闲连接不会被自动回收，也会持续占用PostgreSQL的连接数。

总结 #

PostgreSQL只是在连接数达到上限时抛出错误，问题根源是你的程序对数据库连接的管理不当，存在连接泄漏或连接池滥用的情况。建议从上述方向排查代码，修复连接释放逻辑，而不是依赖降低连接池max值来掩盖问题。

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