pg_upgrade 报 could not load library：检查扩展缺包和 adminpack 移除
pg_upgrade 的共享库检查失败时，区分目标版本缺少扩展包与 adminpack 已被移除，核对旧库调用和删除影响，再重新检查升级条件。
升级 PostgreSQL 主版本时，pg_upgrade --check 在库检查阶段停下，报 could not load library "$libdir/adminpack"，或提示无法访问另一个扩展的共享库。先看报错指向哪一个库：目标版本缺少仍受支持的扩展安装包，与目标版本已经移除该扩展，需要不同的处理办法。
PostgreSQL 17 移除了 adminpack，升级到 17、18 时不能靠寻找新的 adminpack.dll，或复制旧版本的 DLL、.so 文件解决。库文件存在也不代表它与新服务器兼容。
确认检查的是哪一套服务器
使用目标新版本 bin 目录中的 pg_upgrade，核对传给它的旧、新数据目录及可执行文件目录。不要只看终端默认 PATH 里的版本：Windows 服务、宿主机和容器可能各自指向不同的安装位置。
保留本轮检查输出及生成的库检查报告，按其中的数据库名称和库名排查。若报告列出多个问题，处理一个库以后仍需重新检查，不能把第一条错误消失当作升级准备完成。
下面的只读 SQL 应在旧集群的相关数据库中执行，用来确认连接目标和已安装扩展：
SELECT current_database(), current_setting('server_version');
SELECT extname, extversion
FROM pg_extension
ORDER BY extname;
pg_extension 记录当前数据库中的扩展。在一个业务库里查不到 adminpack，不能排除另一个数据库或模板库仍装有它。按报告逐个确认，不对所有数据库批量删除扩展。
仍受支持的扩展，安装与新服务器匹配的库
如果报错指向的扩展在目标 PostgreSQL 版本仍受支持，检查目标安装是否包含对应的扩展包，以及包是否匹配新服务器的主版本、平台和架构。自编译模块也应按新版本重新构建。
安装位置以目标服务器的扩展目录为准。只在旧服务器或宿主机安装，而实际升级工具使用另一套目标二进制，仍可能报找不到库。
这一步是准备目标版本的共享库和支持文件。不要提前在新集群执行 CREATE EXTENSION 来“补齐”旧扩展的数据库对象：pg_upgrade 会从旧集群迁移这些定义。扩展自身若有升级要求，还要按它支持的升级路线处理。
若你走的是逻辑导出与恢复，而不是 pg_upgrade，并且报错为 server version mismatch，应另查执行备份的 pg_dump 客户端版本。它与共享库加载检查不是同一个环节。
adminpack 已移除，先查清旧库是否还需要它
adminpack 提供过管理服务器文件等函数。即使最初由旧管理工具安装，也不能据此认定现在无人使用；运维脚本和自定义函数可能仍调用其中的对象。
在旧数据库的 psql 中，可以查看扩展及其成员：
\dx+ adminpack
这是 psql 命令，不是普通 SQL。核对显示的函数与现有管理任务、脚本及数据库对象，判断是否还需要它们。扩展成员列表不会告诉你所有数据库外部的调用方，仍须检查实际使用情况。
如果仍需要这些功能，先确定目标版本可用的替代方案并迁移调用方，保留旧集群与备份，暂缓升级。不要从旧版本目录复制 adminpack.dll，也不要为了通过检查而删除业务依赖。
只有确认该数据库不再使用 adminpack、已保存可恢复的旧集群备份及相关定义，并由扩展所有者执行时，才考虑在旧数据库移除它：
DROP EXTENSION adminpack;
这会删除扩展成员，以及显式声明依赖该扩展的例程，并非只删除一条安装记录。默认的 RESTRICT 会阻止某些其他依赖对象被连带删除，但不等于保证业务无影响。如果删除报依赖错误，停止并核对对象，不追加 CASCADE。
重新检查，再决定是否进入正式升级
处理完目标库安装或旧扩展兼容问题后，使用相同的旧、新目录重新运行新版本的 pg_upgrade --check。正式计划采用 --link 等模式时，检查阶段也要带对应选项，以覆盖该模式的限制。
只有整轮检查通过，才进入已有的停机、备份、升级与应用验证流程。--check 通过只是兼容性预检，不证明升级已完成、应用已恢复，或备份可以成功恢复。
保留原库检查报告、扩展定义和处理记录。若移除扩展后发现调用方仍需要它，应在正式升级前，按备份和旧版本环境恢复需要的对象并复核调用；不要继续启动新集群来碰运气。尤其在 --link 模式下，新集群启动会影响旧集群继续使用的条件，不能把“目录还在”当作随时可回退。
如果最初故障发生在 Docker 挂载 /var/lib/postgresql/data 时，先按PostgreSQL 18 的数据目录与主版本升级检查区分挂载失败和数据库格式升级，再选择适合的升级路线。