遇到 PostgreSQL 报错 FATAL too many connections，最直接的处理是修改配置文件中的 max_connections 参数并重启服务，或者引入连接池中间件。调整前需评估服务器内存，避免因连接数过高导致内存溢出。

命令速用版

使用以下 SQL 命令查看当前连接限制和使用情况：

SHOW max_connections;
SELECT count(*) FROM pg_stat_activity;
SHOW superuser_reserved_connections;

为什么会这样

PostgreSQL 默认限制最大连接数是为了防止服务器内存耗尽。

数据库启动时会预分配连接所需的内存结构，每个客户端连接都会占用一定的内存资源。当活跃连接数达到 max_connections 设定值时，新连接请求会被拒绝。此外，系统会预留少量连接给超级用户，确保管理员在连接满时仍能登录处理问题。

分步处理

步骤 1：检查当前配置

登录数据库执行 SHOW max_connections; 确认当前上限。查看配置文件位置通常位于 /etc/postgresql/版本/main/postgresql.conf 或数据目录下的 postgresql.conf。

步骤 2：修改配置文件

找到 max_connections 参数，取消注释并修改数值。例如设置为 200：

max_connections = 200

步骤 3：重启服务

max_connections 参数修改后必须重启服务才能生效，重载配置无效。使用系统命令重启：

sudo systemctl restart postgresql

步骤 4：替代方案（连接池）

如果连接数需求很大，建议部署 PgBouncer 等连接池中间件，应用连接连接池而非直连数据库。

怎么验证是否生效

重启后再次执行 SHOW max_connections; 确认数值已变更。尝试建立新连接，观察是否不再报错。同时使用系统监控工具观察服务器内存使用率，确保没有因连接数增加导致内存溢出。

常见坑

1. 内存溢出风险：增加连接数会线性增加内存消耗，操作系统可能触发 OOM Killer 杀死数据库进程。

2. 超级用户预留：即使连接数满，超级用户仍可登录，这是由 superuser_reserved_connections 控制的，默认通常为 3。

3. 重启必要性：该参数属于 POSTMASTER 级别，修改后必须重启实例，仅 reload 无效。

常见问题

默认最大连接数是多少？

PostgreSQL 编译时的默认最大连接数通常是 100，具体值取决于初始化集群时的设置。

修改后需要重启数据库吗？

需要，max_connections 参数修改后必须重启数据库服务才能生效。

为什么超级用户还能登录？

系统预留了 superuser_reserved_connections 个连接槽位专供超级用户使用，防止管理员无法登录处理故障。

参考来源

• PostgreSQL Documentation: Server Configuration - Connection Settings, https://www.postgresql.org/docs/current/runtime-config-connection.html