pg_restore 报 transaction_timeout：检查恢复工具的实际版本

恢复 PostgreSQL 备份时，日志在初始化阶段出现：

ERROR: unrecognized configuration parameter "transaction_timeout"
Command was: SET transaction_timeout = 0;

目标服务器如果是 PostgreSQL 16 或更早版本，先核对真正执行恢复的 pg_restore。transaction_timeout 是 PostgreSQL 17 增加的参数；17 版恢复工具会在设置恢复会话时发送这条 SET，并不要求它原本就存在于备份里的某张表定义中。

查恢复进程，不只查导出工具

在执行恢复的环境中检查工具路径与版本。下面是 POSIX shell 示例：

command -v pg_restore
pg_restore --version
command -v pg_dump
pg_dump --version

服务器版本通过连接目标数据库查询：

SHOW server_version;

终端显示的版本只说明这个终端的调用结果。任务如果使用绝对路径、容器或图形界面，需要检查对应执行环境；不要在宿主机看到 16 版工具，就认定另一个备份容器也使用 16。

pgAdmin 可在 File → Preferences → Binary paths 检查外部工具目录。以恢复任务实际使用的可执行文件路径为准，再直接检查该文件的版本。pgAdmin 的版本号和数据库服务器的版本号，均不能代替 pg_restore 的版本。

归档格式决定处理方式

自定义格式、目录格式等归档由 pg_restore 读取。17 版 pg_restore 会在恢复会话初始化时生成 SET transaction_timeout = 0；只检查 pg_dump，或试图在归档二进制文件中删除这个字符串，处理不到这一层。

普通 SQL 文件则由 psql 执行。较新 pg_dump 输出的 SQL 也可能包含该设置，但 SQL 文件和二进制归档需要分别处理。不要对自定义格式文件执行文本替换，否则可能损坏归档。

若源库与恢复目标都为 PostgreSQL 16，通常应使用合适的 16 版工具重新导出，并使用匹配工具在独立的空测试库验证恢复。较旧 pg_restore 如果无法读取已有归档的格式版本，需要重新导出；换一个可执行文件并不保证旧工具能读取所有新归档。

若源库实际为 17 或更高主版本、目标却为 16，问题还涉及向旧版本迁移。新版本导出的定义可能使用旧服务器不支持的语法或功能；删除一条 SET 不能保证兼容。应先核对迁移是否受支持，再处理对象和数据兼容性。源服务器比 pg_dump 更新导致的导出拒绝，可另看server version mismatch 的客户端检查。

日志继续输出，不等于恢复成功

默认情况下，pg_restore 遇到数据库执行错误会继续，并在最后报告错误数量。因此初始化报错后仍出现建 schema、建表或导入数据日志，并不能证明最终恢复完整。

核对任务退出码和完整错误清单，再检查目标对象、数据、索引、约束与必要权限。配置了 --exit-on-error 时，发送 SQL 出错会停止；--single-transaction 还涉及整轮事务的提交或回滚，不能把默认继续模式的结果套过去。

修正工具路径之后，先在独立测试库验证，再安排正式恢复。失败的目标库可能已经留下部分对象或数据；不要直接重复导入，也不要为了消除重复对象错误临时加 --clean。保留原归档、任务配置与日志，按已确认的恢复方案处理目标库状态。