我来帮你拆解下问题根源，以及对应的解决办法：

核心问题分析 #

你遇到的两个错误其实是连锁反应，根源有两个：

1. 参数混淆：你在pg_dump和pg_restore命令里把-p参数用错了——-p是指定数据库端口（比如默认的5432），而不是密码！密码需要用-W选项（执行时交互式输入），或者通过环境变量/配置文件传递，避免明文暴露。
2. --create参数的使用逻辑误解：--create参数的作用是让pg_restore先创建目标数据库，但它需要先连接到一个已经存在的数据库（比如默认的postgres库）才能执行创建操作，而你直接指定了不存在的temp作为连接目标，导致第一步连接就失败，后续的表恢复自然也会报"Relation does not exist"。

正确的恢复步骤 #

1. 修正命令参数，使用已存在的数据库作为连接入口 #

把-d的目标改成默认存在的postgres数据库，pg_restore会自动创建temp库并完成数据恢复：

# 方法1：交互式输入密码（推荐，更安全）
pg_restore --clean --create -d postgres -h server -p 5432 -U user -W dump.sql

# 方法2：通过环境变量传递密码（适合脚本场景）
# Linux/macOS
export PGPASSWORD=your_password
pg_restore --clean --create -d postgres -h server -p 5432 -U user dump.sql

# Windows cmd
set PGPASSWORD=your_password
pg_restore --clean --create -d postgres -h server -p 5432 -U user dump.sql

2. 验证权限 #

确保执行命令的user账号拥有：

• 连接到postgres数据库的权限
• 创建新数据库temp的权限
• 往temp库中写入表数据的权限

额外说明 #

• 你的备份命令pg_dump -Fc ...是没问题的，自定义格式（-Fc）完美支持pg_restore的--create和--clean参数。
• --clean参数会在恢复前清理目标库中已存在的同名对象，但因为是全新创建temp库，这个参数其实可以省略，不过保留也不会有问题。

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