Docker环境PostgreSQL升级时pg_upgrade_dump日志文件存放位置

pg_upgrade_dump_1.log、pg_upgrade_internal.log这类pg_upgrade运行时生成的日志，默认存放在你执行pg_upgrade命令时的当前工作目录，不会自动写入PostgreSQL的数据目录或系统日志目录。

常规定位方式 #

• 如果你是直接在操作系统终端执行pg_upgrade命令，直接回到执行升级命令时所在的目录就能找到对应日志，也可以执行命令快速搜索：

# 搜索当前目录及子目录下的pg_upgrade日志
find . -name "pg_upgrade*.log"

如果记不清当时的执行路径，可以执行全局搜索：

find / -name "pg_upgrade_dump_1.log" 2>/dev/null

Docker部署场景的特殊说明 #

你当前是迁移到Docker安装的PostgreSQL 14.3实例，根据执行pg_upgrade的位置不同，日志位置分两种：

• 如果你是在宿主机上挂载新旧两套PG的数据目录，用宿主机的pg_upgrade二进制执行升级：日志就在宿主机上执行升级命令时的工作目录
• 如果你是进入PostgreSQL 14的Docker容器内部执行的pg_upgrade命令：日志默认在容器内执行命令时的工作目录下，通常直接exec进入容器的默认工作路径是/var/lib/postgresql，可以直接执行命令把日志拷贝到宿主机查看：

# 将<pg14容器名/ID>替换为你实际的PostgreSQL 14容器标识
docker cp <pg14容器名/ID>:/var/lib/postgresql/pg_upgrade_dump_1.log ./
docker cp <pg14容器名/ID>:/var/lib/postgresql/pg_upgrade_internal.log ./

如果默认路径没找到，直接在容器内全局搜索即可：

docker exec -it <pg14容器名/ID> find / -name "pg_upgrade*.log" 2>/dev/null

补充说明：pg_upgrade_dump_1.log文件名里的数字1对应数据库OID，本次报错里的1对应的是template1库，查看日志时优先筛选ERROR级别的条目即可快速定位故障，常见故障原因包括旧库残留无效依赖、扩展/自定义数据类型版本不兼容、文件系统权限不足等。

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