1. 升级前的决策为什么要从 PostgreSQL 14 跑到 151.1 PostgreSQL 15 带来的关键改进如果你在 Oracle Linux 7.9 上维护一套 PostgreSQL 14 实例最该优先做的事不是直接下载新版本安装包而是先想清楚一个问题升级到 15 到底能换来什么。PostgreSQL 15 虽然不是一次颠覆性的重写但值得关注的改进非常集中。首先是MERGE命令被正式引入之前在业务代码里经常要用INSERT ... ON CONFLICT DO UPDATE来处理“有则更新、无则插入”的逻辑15 提供了更符合 SQL 标准的写法迁移老业务时会顺手很多。其次逻辑复制在 15 里开始支持“行过滤器”和“列列表”意思是你可以在发布端按WHERE条件过滤要复制的行也可以只复制指定的列这对做数据分层、表级同步来说是实打实的功能补全。再看性能和运维层面的变化。15 对 WAL 日志默认启用了压缩在高并发写入场景下归档和主从传输的带宽压力会有明显缓解。pg_basebackup生成了备份清单文件备份的完整性和一致性校验比 14 更容易做。分区表在 15 里也做了不少优化尤其是ENABLE/DISABLE ROW MOVEMENT的处理更加成熟对走表分区的系统来说升级后的查询计划质量通常会有改善。这些改动叠加在一起构成了一个足够充分的升级理由你不需要为尝鲜而升级但为了这些生产级特性从 14 跨越到 15 是划算的。1.2 环境基线确认不能省动手之前先把环境摸一遍。标题里写了 Oracle Linux 7.9这个系统的内核版本是 3.10 系其实和 RHEL 7 兼容的方向一致。PostgreSQL 15 官方提供的二进制包对 glibc、libstdc 都有最低版本要求7.9 默认的软件源里这些基础库完全够用但不代表你可以跳过检查。我在升级前会依次执行下面几条命令cat /etc/oracle-release uname -r rpm -q glibc libstdc psql --version pg_config --version pg_ctl --version注意最后三条命令的输出路径要确保你实际调用的版本是你要升级的旧版本 14而不是系统里已经装了但从未启用过的其他 PostgreSQL 主版本。有的服务器之前调试过其他版本PATH环境变量可能会让psql指向错误目录。我习惯用绝对路径来确认比如/usr/pgsql-14/bin/psql --version。如果连路径都不确定先查一下rpm -qa | grep postgresql systemctl status postgresql-14另外还需要确认数据目录位置、磁盘剩余空间和文件系统类型。PGDG 系列 RPM 默认会把 14 的数据目录放在/var/lib/pgsql/14/data15 放在/var/lib/pgsql/15/data。升级过程中需要额外一份数据目录的空间所以df -h必须同时检查旧数据目录所在分区以及新数据目录所在分区。如果旧库已经 500GB那新分区至少也得预留 500GB 以上空间。除了数据本身升级过程还需要一部分临时空间存放 dump 文件公式大概是“旧实例数据目录总大小 × 1.1 倍”这是我在实际部署时比较保守的估算方式。2. 升级方案选型pg_upgrade 还是逻辑迁移2.1 两种主流升级方式的对比PostgreSQL 跨大版本升级绕不开的路线无非两种物理升级pg_upgrade和逻辑迁移pg_dump/pg_restore。这两种思路差异很大。pg_upgrade直接操作数据文件本质上是把旧版本的目录结构转换为新版本能够识别的格式整个过程不涉及业务数据的增删改查因此速度很快几百 GB 到 TB 级的库也只需要分钟级或小时级停机窗口主要由数据量决定但通常远远小于逻辑迁移。逻辑迁移则完全不同。它需要先把数据导出成 SQL 或其他格式再由新实例重新导入。对一个大库来说导出和导入都是沉重的 I/O 压力而且整个过程中生产事务必须冻结或者至少保证导出的数据是一致快照。遇到pg_dump不支持的某些高级对象例如物理复制槽、统计信息或者某些第三方扩展的二进制对象逻辑迁移可能根本无法完整还原。两者适用范围也不是完全互斥。比如旧库从 9.x 这种特别老的版本直接跳到 15pg_upgrade可能不支持跨多代的二进制升级这时候逻辑迁移反而是唯一选择。但标题里的场景是 14 到 15中间只隔一个主版本pg_upgrade是官方明确推荐的路径也是停机时间最短的路径。实际业务场景里如果停机窗口只有 30 分钟逻辑迁移基本做不到pg_upgrade却有很大希望。2.2 我选择 pg_upgrade 的深层理由有人可能会问既然有更稳妥、更通用、能顺便清理数据的逻辑迁移为什么还要用pg_upgrade我对这类问题的回答是要看你想要的是“可控性”还是“兼容性”。逻辑迁移在“兼容”上确实更稳因为它不依赖数据文件二进制格式到了新版本里一切都是全新生成的。但它有两个隐藏风险第一导出的对象清单非常长视图、函数、触发器、权限、COMMENT、序列、自定义类型都可能出现细节丢失尤其是某些对象依赖顺序错乱时恢复过程中要手工干预第二导入后还需要重新跑统计信息、重建索引、更新扩展整体操作时间拉满后对运维人员的耐心和技术水平要求都很高。反过来看pg_upgrade它没有把数据打散再重组的步骤而是直接把旧数据文件映射为新的格式保留所有对象 OID、角色、权限和各种边界行为。执行过程中需要人工干预的点集中在“预检”“启动”和“验证”每一个阶段都有明确的输出日志和错误提示。从运维角度看这种可预期性非常重要你知道机器上正在发生什么也知道失败了该从哪里恢复。而且 14 到 15 之间的pg_upgrade已经非常成熟只要环境检查做得充分成功率相当高。2.3 升级前必须完成的备份策略无论选择哪种升级方式备份都不可省。pg_upgrade本身并不会帮你备份旧库它只是尝试把旧目录转换到新目录。有些新手会以为只要数据库没有启动数据文件就不会被改动事实上在 copy 模式下旧目录确实不会被动但前提是你操作正确。一旦你在验证阶段出错比如不小心写入了新库或者使用--link模式后旧目录被硬链接复用那么回滚就只能依赖备份。我通常会在升级前做两层保险第一层用pg_basebackup做一次物理备份留在一台独立的机器或者至少另一个分区第二层直接对数据目录做一次镜像快照比如 LVM 快照或 tar 归档。很多云环境支持磁盘快照这比任何数据库层面的备份都简单直接。备份完成后务必要做一次恢复演练不要只看到备份文件存在就以为万事大吉。pg_basebackup备份完成后至少要在新目录里执行一次pg_ctl start确认能启动并读到数据才能认为这份备份可用。3. 实操在 Oracle Linux 7.9 上用 pg_upgrade 完成升级3.1 安装 PostgreSQL 15 软件包Oracle Linux 7.9 安装 PostgreSQL 15建议直接使用官方社区构建的 RPM 包也就是 PGDG 仓库。安装方式并不复杂但要特别注意 14 和 15 的 RPM 文件是并行安装的它们不会互相覆盖这也给pg_upgrade创造了条件两个版本的二进制同时存在于系统各自的默认数据目录路径也完全隔离。先配置仓库。PGDG 为 Linux 发行版提供了统一的pgdg-redhat-repoRPM安装之后系统里会新增多个仓库标签。在 7.9 上通常使用yumyum install -y https://download.postgresql.org/pub/repos/yum/reporpms/.../pgdg-redhat-repo-latest.noarch.rpm上面的省略号部分需要替换为对应实际地址最好先下载到本地再看一下版本信息。安装仓库完成后建议优先搜索可用的 PostgreSQL 15 包yum list available | grep postgresql15 yum install -y postgresql15-server postgresql15-contribpostgresql15-server是核心服务包postgresql15-contrib包含很多常用扩展例如pg_stat_statements、uuid-ossp、postgres_fdw等。如果你的业务依赖其他第三方扩展例如 PostGIS、pgvector也需要额外安装对应的 15 版本扩展包。安装完最好确认一下新二进制路径是否存在ls -l /usr/pgsql-15/bin/initdb /usr/pgsql-15/bin/postgres --version这一步非常重要。很多人装了包之后跑命令时用的还是 14 版本的路径最终导致预检报错或升级到一半才发现操作了两套不同目录。3.2 初始化新数据目录旧实例先不要启动保持停止状态。然后使用 15 的initdb创建一个全新的数据目录。这里有个常见的坑新目录的locale和编码必须和旧实例保持一致或者至少兼容否则pg_upgrade在预检阶段会报 locale mismatch。你可以在旧实例停止前先记录下两个值SHOW lc_collate; SHOW lc_ctype;然后再用同样的参数创建新目录。如果旧实例使用的是默认的en_US.UTF-8那么新实例也这样做mkdir -p /var/lib/pgsql/15/data chown postgres:postgres /var/lib/pgsql/15/data su - postgres -c /usr/pgsql-15/bin/initdb -D /var/lib/pgsql/15/data -E UTF8 --localeen_US.UTF-8如果旧实例启用了数据校验和data_checksums需要在新实例初始化时加上--data-checksums参数。查询旧实例是否启用的方法很简单SHOW data_checksums;如果返回on就在initdb命令后面追加--data-checksums。这一步不强制要求保持一致但建议保持一致否则升级后可能发现旧校验策略被改变影响运行期的检测能力。初始化过程结束后不要急着复制任何配置文件。接下来先让新版二进制对旧目录做一轮预检。3.3 运行预检pg_upgrade --check预检是整个升级流程中最为关键的一环。它不会真正修改数据文件只会检查旧数据目录里的对象是否可以被新版本接受比如旧的本地语言目录、无法识别的数据类型、不兼容的扩展版本等。这个阶段报错并不可怕反而是好事因为问题可以在不影响生产的情况下提前暴露。确保旧实例已经停止然后以postgres身份执行su - postgres -c /usr/pgsql-14/bin/pg_upgrade \ --old-bindir/usr/pgsql-14/bin \ --new-bindir/usr/pgsql-15/bin \ --old-datadir/var/lib/pgsql/14/data \ --new-datadir/var/lib/pgsql/15/data \ --check参数含义很直白分别指定旧版本二进制、新版本二进制以及各自的 PGDATA。--check只会检查不会执行。常见的输出是Checking for valid combination of old and new version、Checking for incompatible roles等一系列检查项最终出现*Clusters are compatible*字样就代表预检通过。如果预检失败建议先把完整输出保存到日志文件逐条处理。最容易出现的几个报错我在后面第 5 节专门展开。需要注意的是预检阶段不要慌着用-m fast启动旧实例来“验证”因为一旦旧库启动你就得再停掉它才能继续。整个过程要保证旧数据目录处于干净停机状态。3.4 正式执行升级预检通过后正式执行命令时把--check去掉su - postgres -c /usr/pgsql-14/bin/pg_upgrade \ --old-bindir/usr/pgsql-14/bin \ --new-bindir/usr/pgsql-15/bin \ --old-datadir/var/lib/pgsql/14/data \ --new-datadir/var/lib/pgsql/15/data这里我没有加--link参数意味着采用 copy 模式。copy 模式会完整复制数据文件到新目录安全性最高旧数据目录在升级结束后依然保持完整回滚时只需要把服务切换回旧目录即可。缺点是需要额外一份数据目录容量的磁盘空间。如果磁盘空间非常紧张可以考虑--link模式它通过硬链接让新旧目录共用数据文件几乎不消耗额外空间速度也快得多。但硬链接一旦建立旧目录里的文件就被复用如果新库启动时出现问题旧数据目录可能已经被新版本进程修改回滚会变得非常困难。所以除非你确定有可靠备份否则我建议普通场景一律先用 copy 模式。执行过程中pg_upgrade会输出进度信息可能停留几秒到几十分钟取决于数据量。完成后会生成pg_upgrade_dump_*.sql等相关文件还会提示你复制配置文件并存档旧数据目录。此时不要急于启动新库先做两件事。第一件事先把旧实例的postgresql.conf、postgresql.auto.conf、pg_hba.conf以及pg_ident.conf复制到新数据目录。注意pg_upgrade不会自动迁移这些配置文件。直接复制可能带来一个问题某些参数在新版本里已经改名甚至完全失效但 PostgreSQL 通常只会告警不会拒绝启动。因此我建议不要直接覆盖而是先备份把新目录里的默认配置改名再复制旧配置。cp -a /var/lib/pgsql/14/data/postgresql.conf /var/lib/pgsql/15/data/ cp -a /var/lib/pgsql/14/data/pg_hba.conf /var/lib/pgsql/15/data/ cp -a /var/lib/pgsql/14/data/pg_ident.conf /var/lib/pgsql/15/data/第二件事检查端口问题。如果旧实例还在监听 5432而新实例也默认监听 5432则启动会冲突。通常升级操作是在同一主机上进行的旧实例已经停止端口自然空出来。但如果还有从库或者其他进程占用 5432就得先把新实例的port改到临时端口成功启动验证后再改回来。3.5 启动新实例并处理配置文件使用 15 版本的pg_ctl启动su - postgres -c /usr/pgsql-15/bin/pg_ctl -D /var/lib/pgsql/15/data -l /tmp/pg15.log start如果是通过 systemd 管理则用systemctl start postgresql-15启动成功后立刻查看日志文件确认没有严重告警。很多在生产环境踩坑的人都会忽略这一步直接让应用连接结果崩溃了才知道是某个配置不兼容导致的。正确的姿势是先看日志再连上去验证。这时候你可能会看到类似unrecognized configuration parameter的告警。这些都是 15 里已经移除或改名的参数。例如wal_keep_segments早先在 13 版本就被改成了wal_keep_size如果旧配置里还留着旧名字新库会直接忽略它。类似的问题不需要立刻删掉但建议记录备用后续清理。3.6 升级完成后的清理和旧目录保留pg_upgrade成功执行之后会生成一个脚本delete_old_cluster.sh这个脚本的作用是删除旧数据目录。千万不要因为它生成出来了就去执行。至少观察一周等业务、监控、备份全部验证通过后再手动执行清理。旧数据目录是回滚的最后保险一旦删除想回滚就只能依赖备份恢复。在保留旧目录的同时别忘了修复新实例的历史对象。升级完成后psql进入新库运行以下 SQL 查看是否有失效对象SELECT nspname, relname, adsrc FROM pg_class c JOIN pg_namespace n ON n.oid c.relnamespace LEFT JOIN pg_attrdef a ON a.adrelid c.oid WHERE c.relkind r AND EXISTS ( SELECT 1 FROM pg_attribute att WHERE att.attrelid c.oid AND att.attisdropped );不过更简单有效的做法是直接运行官方建议的统计信息更新命令我放到下一节。4. 升级后的验证与配置调优4.1 更新统计信息与重建扩展升级完成后新库里的统计信息是空的而且旧库的统计信息格式在 15 里未必有效。如果不做任何处理查询优化器会因为没有pg_statistic数据而走向“毫无直方图”的默认估算导致执行计划严重失真。遇到复杂 JOIN 或分区表时性能可能从毫秒级恶化到秒级。所以启动新库之后第一件事就是重建统计。官方推荐的做法是执行/usr/pgsql-15/bin/vacuumdb --all --analyze-in-stages--analyze-in-stages会分多次执行先小规模采样再逐渐加大最终拿到比较完整的统计信息。对于一个几百 GB 的大库这个过程可能需要几分钟到几十分钟但它不应该跳过。不要图省事只跑一次ANALYZE那样采样精度不够。同时检查已有扩展的版本。如果使用psql查询SELECT * FROM pg_extension;如果某个扩展在 15 里有更新版本运行ALTER EXTENSION extension_name UPDATE;但要注意第三方扩展升级前必须确认新版本的二进制库已经安装到/usr/pgsql-15/lib下否则ALTER EXTENSION会失败。4.2 验证核心业务数据与对象一致性统计信息更新完成后需要做一轮完整的数据一致性验证。这一步不怕慢越细致越好。至少做以下几类检查数据库数量、schema 数量、每个库的表数量、视图数量、序列数量和索引总数。用 SQL 对比最直观SELECT datname FROM pg_database ORDER BY 1; SELECT count(*) FROM pg_class WHERE relkind r; SELECT count(*) FROM pg_indexes; SELECT count(*) FROM pg_proc WHERE pronamespace NOT IN (SELECT oid FROM pg_namespace WHERE nspname LIKE pg_%);如果旧库之前有自定义角色、表空间、COMMENT等也需要随机抽查。pg_upgrade会保留这些对象但不会自动验证它们是否可用。另外如果业务应用依赖某些函数抽几个典型函数跑一遍SELECT * FROM some_business_schema.some_function();对于每一个业务库都执行一次简单查询确认能够返回结果。如果遇到函数或视图引用错误多半是扩展没有正确升级或者函数签名在新版本里发生了变化。这时候不要盲目修改数据库对象先在官方文档里确认相应兼容性意见。4.3 配置参数迁移与差异处理这节可能是最容易被忽略但又是最容易出问题的环节。旧实例的postgresql.conf里通常积累了大量历史调优参数比如shared_buffers、work_mem、maintenance_work_mem、max_connections、checkpoint_timeout等。大部分参数在 15 里仍然有效直接复制过来没问题。但还有一部分经过调整需要人工对比。一个高效的做法是先把旧库没有启动时的配置快照和 15 默认配置做一次 diffdiff /var/lib/pgsql/15/data/postgresql.conf.default /var/lib/pgsql/15/data/postgresql.conf如果 diff 输出里出现某个参数名是旧的需要查询 15 中是否存在替代参数。例如旧版本里常见的rewrite_rule有可能被移除autovacuum_work_mem在 15 中同 14 一样存在但很多细小的参数如vacuum_cleanup_index_scale_factor在 15 里已经被移除了。PostgreSQL 对未知参数不会直接拒绝启动而是记录为 unrecognized parameter 并继续运行但这意味着你原本想通过参数实现的调优生效了——很可能只是你以为生效了实际上它是被忽略的。所以不要只看启动日志没有 ERROR 就认为配置全部生效。我通常会拿SHOW ALL对比关键参数SHOW shared_buffers; SHOW max_connections; SHOW work_mem; SHOW dynamic_shared_memory_type; SHOW huge_pages;如果旧库设置了huge_pagestry但在新环境里没有配置 HugePages 内核参数启动日志可能会报内存映射失败。在 Oracle Linux 7.9 上如果使用 HugePages还需要配合/etc/sysctl.conf里的vm.nr_hugepages配置这往往被忽略。另外还要重点检查shared_preload_libraries。如果旧库加载了pg_stat_statements升级后必须确保新实例也安装并配置了pg_stat_statements扩展否则启动时直接报错。启动失败最典型的原因就是shared_preload_libraries指向了一个在新版本中没有安装的.so文件。这时候要从配置中移除或安装对应的新版本扩展包再重新启动。应用连接层也需要检查。PostgreSQL 15 的服务端默认认证方式没有变化但一些旧版本的 JDBC/ODBC 驱动可能不完全兼容新服务端的某些新特性。升级完以后建议让应用通过一个最小测试页或单条 SQL 验证连接池释放和重新获取连接是否正常。千万不要在业务高峰期直接切换全量流量。4.4 小技巧用 pg_upgrade 生成的日志做验证pg_upgrade执行完后会在新数据目录或当前目录生成pg_upgrade_*.log文件。不要小看这些日志它们不只是过程记录还包含了每个旧表中的数据量、索引数、序列值、扩展版本等信息。升级完成后可以从中抽取部分数据量与新库查询结果对照。例如日志里有一句类似old database namepostgres, new database namepostgres的信息后面跟着具体的表数量。如果新库SELECT count(*) FROM pg_class WHERE relkindr和日志记录吻合基本上说明对象没有丢失。5. 常见问题与回滚方案实录5.1 预检报错locale 不匹配这是我实际处理中遇到最多的一个坑。旧库初始化时用的是C或者POSIXlocale但是新库初始化时用了en_US.UTF-8预检阶段会直接给出mismatch或类似提示。解决办法不是重新初始化新目录而是严格按照旧库的参数重建。我在 3.2 节里特别强调过这一点但很多人还是会在装了系统后使用默认initdb参数导致 locale 变成操作系统的默认值。如果你已经在预检阶段遇到这个问题最快的处理方式是重新初始化新目录rm -rf /var/lib/pgsql/15/data/* # 然后按旧库的 locale 重新 initdb不要想着在预检命令里强行加参数覆盖因为 locale 的一致性直接关系到以后排序和字符串比较的行为。你可以在initdb完成后通过SHOW lc_collate; SHOW lc_ctype;再次确认。5.2 权限和属主问题整个升级过程必须以postgres系统用户运行。如果你习惯用root执行pg_upgrade第一次执行就会报权限错误。不要试图用chown -R postgres:postgres把所有目录都改成 postgres 后继续因为如果操作错误可能覆盖其他系统文件的属主。正确做法是su - postgres -c cd /tmp /usr/pgsql-14/bin/pg_upgrade ...同时确认新数据目录的父目录权限是700。如果新目录下存在root创建的文件也会导致无法读取或启动失败。5.3 空间不足导致升级中断copy 模式下最怕的就是磁盘空间不足。pg_upgrade在复制数据时不会临时压缩它需要与新数据目录大小相当的可用空间。升级到一半发现No space left on device会留下不完整的新目录。处理办法是先清理掉新目录然后重新执行升级。所以在正式执行前一定要用df -h确认。如果你某个节点的空间确实紧张又不想动用--link模式可以考虑先把旧库中不需要的历史归档清理掉或者把pg_wal目录放到另一个分区。如果都不会操作那在一个演练环境里先试一次是最稳妥的方法。5.4 SELinux 策略导致新库无法启动Oracle Linux 7.9 默认启用 SELinuxPGDG 仓库的 RPM 会在安装时注册好默认路径/var/lib/pgsql-15等目录的 SELinux 上下文。如果新库数据目录放在了默认路径下通常不需要额外操作。但如果你把数据目录放在自定义路径比如/data/pg15启动时会遇到Permission denied即使文件权限都是postgres。这时需要为自定义路径恢复正确的上下文restorecon -Rv /data/pg15或者手动设置策略semanage fcontext -a -t postgresql_db_t /data/pg15(/.*)? restorecon -Rv /data/pg15同时如果使用非默认端口还需要在防火墙中放行。Oracle Linux 7.9 通常使用firewalldfirewall-cmd --permanent --add-port5433/tcp firewall-cmd --reload这些细节虽然不在pg_upgrade的教程里但对你启动新库有着直接影响。5.5 回滚方案尽量保住旧目录回滚是整个升级计划中最需要提前设计的一环。copy 模式下旧数据目录在升级期间没有被修改所以回滚只需要两步先停止新实例再启动旧实例。su - postgres -c /usr/pgsql-15/bin/pg_ctl -D /var/lib/pgsql/15/data stop -m fast su - postgres -c /usr/pgsql-14/bin/pg_ctl -D /var/lib/pgsql/14/data start如果新库已经运行了一段时间底层表结构被业务写入了数据回滚会丢失这些新写入的数据所以需要评估是否接受。如果使用了--link模式旧目录已经和新目录共享数据文件回滚就不再安全只能从备份恢复。因此我强烈建议生产环境第一次升级不要使用--link。即使你真的需要--link提速也必须确保升级前完成的pg_basebackup备份可恢复。5.6 一个实际踩坑案例的模拟我模拟过一个场景某套库在升级后启动正常但应用查询某个表时发现结果集顺序和前一天不一样。排查后确认原因是旧库的default_table_access_method是heap而新库中某个参数导致优化器选择了不同的扫描路径。其实这不是升级失败而是一种“隐性行为变化”。PostgreSQL 15 在排序、并行扫描和聚合计算上有不少默认变化。这种问题很难靠pg_upgrade预检发现只能靠升级后的应用回归测试覆盖。所以升级验收清单里应当包含性能对比抽几个核心业务查询记录执行计划和耗时和升级前对比。如果出现明显恶化可以通过调整work_mem、random_page_cost或enable_*参数把执行计划拉回原有水平。6. 踩坑心得与建议这次升级流程走下来我最大的体会是不要把注意力全部放在pg_upgrade命令本身真正的难点都集中在“升级之外”。比如你用什么版本的二进制、新旧目录的 locale 是否一致、磁盘空间够不够、SELinux 策略是否匹配、旧配置文件里有没有被 15 移除的参数、扩展包是否安装齐全。每一个环节单独拿出来都不复杂但串在一起任何一个坑都可能让你在停机窗口内手忙脚乱。如果你现在正准备升级我会建议你先做一次完整演练。拿一台不在生产链路上的机器装好 14 和 15造一份和生产相近的数据量完整走一遍初始化、预检、复制、启动、更新统计值、验证业务 SQL。演练结束之后再回到生产环境操作你的信心会完全不一样。演练时最好把每个阶段产生的日志和输出都保留下来后续遇到问题也好对照。最后再分享一个小技巧在升级前用pg_proc、pg_class、pg_attribute这些元数据表导出全量对象清单升级后再导一份用diff做对比。这样即使某些对象没有被pg_upgrade报告异常你也能在第一时间发现细微的对象丢失。毕竟数据文件转换这件事已经高度自动化了但运维的责任从来不是按下按钮而是确认按钮按下去之后一切都正常。