当前位置：首页 > news >正文

PostgreSQL报错“maximum number of prepared transactions reached”原因及高效解决方案解析

news 2025/8/10 15:03:11

PostgreSQL 报错：maximum number of prepared transactions reached 解决方案

在使用 PostgreSQL 数据库时，可能会遇到如下报错：

ERROR: maximum number of prepared transactions reached
HINT: Increase max_prepared_transactions (currently 10).

这通常发生在使用 分布式事务（Two-Phase Commit, 2PC） 的场景中，例如：

PostgreSQL 中的参数 max_prepared_transactions 用于控制允许同时存在多少个 已准备但尚未提交或回滚的事务。

当你使用 PREPARE TRANSACTION 时，事务将被标记为“已准备”，此时还未完成最终提交或回滚。如果没有及时处理这些事务，就会导致积压，从而超出默认限制（默认值为 10）。

SHOW max_prepared_transactions;

查看当前所有已准备的事务：

SELECT * FROM pg_prepared_xacts;

手动提交或回滚这些事务：

COMMIT PREPARED 'transaction_id';
-- 或
ROLLBACK PREPARED 'transaction_id';

✅ 注意：transaction_id 是 pg_prepared_xacts 表中 transaction 字段的值。你需要根据实际情况选择是执行 COMMIT PREPARED 还是 ROLLBACK PREPARED。

打开 PostgreSQL 安装目录下的 postgresql.conf 文件，找到并修改以下参数：

max_prepared_transactions = 100

⚠️ 建议：max_prepared_transactions 应设置为大于等于 max_connections 的值，避免在高并发场景下由于预备事务数达到上限而触发错误。

如果你不清楚配置文件位置，可以使用如下 SQL 语句查询：

SHOW config_file;

修改完 postgresql.conf 配置文件后，需重启数据库服务使参数生效。

以 Linux 系统为例：

# 使用 systemd 管理的系统（如 CentOS 7+, Ubuntu 16+）
sudo systemctl restart postgresql# 如果使用的是 service 命令管理 PostgreSQL
sudo service postgresql restart

验证参数是否已生效：

SHOW max_prepared_transactions;

避免长时间不提交的 Prepared 事务
在使用 PREPARE TRANSACTION 后，如果未及时提交（COMMIT PREPARED）或回滚（ROLLBACK PREPARED），这些事务将持续占用资源，如内存、WAL 日志等。应确保业务流程完整，及时处理每一个预备事务。
定期监控 pg_prepared_xacts
建议通过定时脚本或接入数据库监控系统（如 Prometheus + PostgreSQL Exporter），周期性地检查 pg_prepared_xacts 视图，发现长期未处理的事务并进行干预处理。
数据库异常重启风险
如果数据库在存在 Prepared 状态事务时发生宕机，重启过程中可能导致数据库启动缓慢或事务阻塞，甚至出现数据一致性风险。因此应设置好告警与超时控制，避免长期存在未提交事务。

如果你使用的是 Postgres-XC、Postgres-XL、Citus 等分布式 PostgreSQL 集群，以下是额外注意事项：

涉及节点包括：

应在所有节点的 postgresql.conf 配置文件中设置：

max_prepared_transactions = 100

然后分别重启每个节点：

sudo systemctl restart postgresql

报错信息	原因	解决方案
maximum number of prepared transactions reached	分布式事务或 XA 操作未及时提交，导致 `pg_prepared_xacts` 中积压事务数超过默认限制（默认 10）	1. 查看并清理 `pg_prepared_xacts` 中的事务 2. 提高 `max_prepared_transactions` 参数并重启数据库 3. 检查并优化业务逻辑，确保事务及时结束