1. 升级思路与方案选型1.1 为什么非得做这个小版本升级先聊场景。某个生产环境的 PostgreSQL 还在跑 12.2版本有点老了12.2 到 12.7 之间修了不少东西包括一些复制槽位的稳定性修复、vacuum 相关的性能问题、还有索引扫描的边界情况不升确实有点睡不着觉。而当时这套库是用源码编译方式装到指定目录的既没有用官方仓库的 RPM也没有用 apt数据目录、配置文件、扩展都散落在自己的目录体系里。这种环境最大的问题在于不能像 RPM 安装那样直接yum update或dnf update一把梭必须手动下载新版本源码、重新编译安装再做一次受控的重启切换。小版本升级的逻辑其实很朴素12.x 系列内部的数据目录格式和系统表结构在小版本之间不会变更所以不需要走 pg_upgrade 那套迁移流程更不需要 dump 再 restore。核心动作就两个——把旧的二进制文件替换成新版本二进制然后以新二进制启动原来的数据目录。听起来简单实际操作里坑不少尤其是源码编译环境下编译参数不一致、第三方扩展没跟着重编、二进制和动态库版本不匹配这些都会让你在启动的那一刻收到莫名其妙的服务启动失败。这篇文章不是从零教你编译安装 PG 的而是偏重“升级”这件事。我假设你已经有一台跑着 PG 12.2 的服务器PG 是源码编译装在/usr/local/pgsql之类的目录下现在要把它升到 12.7。如果你还在用 RPM 或者云数据库托管那这篇文章的操作思路可以参考但具体命令不完全适用。1.2 源码编译升级与 RPM 升级的差异用 RPM 或 apt 安装的 PG二进制统一放在发行版约定好的路径里比如/usr/pgsql-12/bin升级时包管理器会自动帮你处理二进制覆盖、服务脚本更新、依赖校验这些事。源码编译安装则是你自己掌控一切路径和编译选项升级时没有一个包管理器替你做依赖检查容易漏掉的就是 contrib 模块和第三方扩展。还有一点RPM 包升级时一般会顺手帮你在postgresql12-upgrade这类脚本里做服务停止和启动的编排源码编译升级则完全要自己执行自己停库fast 模式自己确认编译参数自己编译安装自己启动并验证听起来多但每步都清楚可控这也是我推荐源码编译环境尽量保持“同一套参数从一而终”的原因。若你最初编译时开了--with-perl、--with-python、--with-pgport升级时这些选项一个都不能少不然新二进制和你之前装的那些扩展、语言绑定就全对不上号了。很多人不看pg_config --configure的输出直接./configure一把默认参数就 make install结果升级完发现端口从 5432 变了PL/Python 不可用了之前能用的某个扩展报错找不到依赖库这种“升级成功但业务已经受影响了”的情况其实比升级失败更让人头疼因为你得逐项排查是哪个编译特性丢了。1.3 小版本升级与大版本迁移的本质区别有必要把这两件事彻底分开。PG 12.2 升到 12.7 属于小版本升级官方文档里明确说这种升级不需要 dump/restore也不需要 pg_upgrade。只要新版本的 PostgreSQL 在启动时遇到比它更老的PG_VERSION文件它会自动做兼容处理继续沿用原有数据目录。但如果是 PG 12 升到 PG 13 或更高版本那就是大版本升级需要走 pg_upgrade 或者逻辑导出导入因为系统表结构变了、数据文件布局变了甚至一些函数的内部实现都变了同一个数据目录不能直接让新版本认领。我在实际工作里见过有人拿小版本升级的思路去搞大版本升级直接把 PG 14 的二进制指到 PG 12 的数据目录上启动后日志里报了一堆database files are incompatible with server的错误。这就是没搞清“小版本升级到底在升什么”。小版本升级还有一层特殊价值它是在同一个大版本号内做 bugfix因此业务影响面极小。比如 12.2 和 12.7 之间官方 release notes 里列的修复项包括逻辑复制解码的崩溃问题、GIN 索引 vacuum 时的空间回收效率、以及并行查询中的某些死锁情况这些都是运行时行为层面的修补不会改变 SQL 语义也不改变存储格式。所以你完全可以在业务低峰期完成升级不需要走迁移窗口部署的复杂度和风险都比大版本升级低一个量级。2. 升级前的准备工作2.1 盘点现有编译参数这是整个升级流程里我认为最不能省的一步。源码编译安装的 PG编译时敲了哪些选项直接决定了新版本二进制要复刻哪些配置。获取方法很简单/usr/local/pgsql/bin/pg_config --configure输出长这样configure --prefix/usr/local/pgsql --with-pgport5432 --with-perl --with-python --with-openssl --with-libxml --with-libxslt你把这个输出原封不动记下来后面 configure 的时候直接照抄别自己发挥。比如原来没开--with-python升级时突然加了这不叫增强这叫给自己挖坑——因为 PG 检测到新的 configure 选项后会在编译期编译对应模块但你可能根本没装好 Python 的开发头文件结果是编译直接中断或者编译过了但运行时加载失败。还有几个容易忽略的--with-pgport如果原来设了非默认端口比如 15432升级时忘了带新二进制默认端口就变成 5432启动时端口冲突或者业务拿着 15432 连不上--with-uuidossp如果原来指定了 uuid 生成方式忘了带会让uuid-ossp扩展行为异常--with-icuPG 12 开始支持 ICU 排序规则如果原来开着升级后忘了数据库里的COLLATE规则可能受影响建议把 pg_config 的输出保存成一个文件比如/root/pg12-configure-args.txt升级完新版本后对比一下。2.2 数据目录与配置备份就算小版本升级官方说风险低备份这条红线不能碰。因为一旦编译出来的二进制有问题或者启动后数据文件报错你还得把旧二进制恢复回去。备份至少做两层第一层是文件级备份把数据目录的配置文件、pg_hba.conf、postgresql.conf、pg_ident.conf复制一份到独立目录mkdir -p /backup/pg-conf-backup cp $PGDATA/postgresql.conf /backup/pg-conf-backup/ cp $PGDATA/pg_hba.conf /backup/pg-conf-backup/ cp $PGDATA/pg_ident.conf /backup/pg-conf-backup/第二层是物理备份用 pg_basebackup 做一个全量在线备份这样可以随时回滚到升级前的状态pg_basebackup -h localhost -U postgres -D /backup/pg12-full-backup -Ft -z -P这里用的-Ft表示 tar 格式输出-z表示压缩-P显示进度。备份完成后务必验证一下检查 tar 文件能否正常解压最好在另一台机器上恢复出来做一次只读启动验证。这一步能发现备份文件是否有效而不是等出事了才知道备份不可用。如果数据库特别大备份时间很长业务上又不允许长时间锁表那么 pg_basebackup 的在线备份机制不会阻塞正常读写它基于 WAL 的复制原理工作所以可以放心在生产环境执行。但要注意如果开了复制槽replication slotpg_basebackup 默认不会自动备份复制槽信息如果这是一套主从环境升级主库前最好确认从库的状态和槽位情况。2.3 扩展与依赖项摸底源码编译环境里最容易漏掉的是 contrib 模块和第三方扩展。PostgreSQL 12.2 安装时你大概率执行过进入 contrib 目录再 make install 的操作。比如pg_stat_statements、pgcrypto、uuid-ossp、btree_gist这些都属于 contrib 范畴。在升级前先盘点当前数据库里到底用了哪些扩展SELECT name, default_version, installed_version FROM pg_available_extensions WHERE installed_version IS NOT NULL;记录下来升级完二进制之后对应的.so文件和 SQL 脚本也必须更新。PostgreSQL 12.7 的源码包里的 contrib 目录会附带对应的扩展 SQL 和动态库你需要在 make install 之后进入旧的扩展目录重新编译安装。另外检查一下是否装了pgbouncer、repmgr这类外部工具它们可能会链接 PG 的 libpq 库。升级后如果只替换了 PostgreSQL 服务端二进制没动 libpq通常没太大影响但如果你编译时改了--prefix把新版 PG 安装到了新目录那么旧的外部工具可能还在链接旧 libpq这种情况一般建议顺手把 libpq 相关软链接也更新一下。最后检查编译所需依赖是否齐全尤其是否还保留着源码编译工具链gcc / makereadline-dev / libreadline-devzlib1g-devbison / flex编译 PG 源码必需openssl-dev如果 configure 里有 --with-openssl很多服务器在装完 PG 之后会顺手清理编译依赖升级时才发现没 gcc临时装又要走一遍软件源。所以这一步提前做能省半天。3. 源码编译安装新版本3.1 下载源码与完整性校验升级用的源码包地址官方是https://ftp.postgresql.org/pub/source/v12.7/postgresql-12.7.tar.bz2下载之后建议校验一下压缩包完整性。官方在源码包旁边提供了对应的.sha256或.md5文件SHA256$(curl -s https://ftp.postgresql.org/pub/source/v12.7/postgresql-12.7.tar.bz2.sha256 | awk {print $1}) echo ${SHA256} postgresql-12.7.tar.bz2 | sha256sum -c -校验通过再解压。这一步很多人忽略但下载源偶尔会有 CDN 断裂或代理缓存导致包损坏的情况如果解压时报错或者编译时出现奇怪的语法错误先回头检查包是不是完整。解压tar -xjf postgresql-12.7.tar.bz2 cd postgresql-12.73.2 configure 参数一致性详解这是整个升级流程中真正的“胜负手”。前面你通过 pg_config 拿到了旧版本的 configure 参数现在直接照着跑./configure --prefix/usr/local/pgsql --with-pgport5432 --with-perl --with-python --with-openssl --with-libxml --with-libxslt注意几点第一--prefix一定不要改。如果你之前把 PG 装在/usr/local/pgsql升级时也必须是这个目录。否则你会把新版本装到一个全新的位置老位置还是原来的 12.2业务连的 psql 和 server 还是旧版本等于没有升级。第二如果源码包里的 configure 检测不到某个依赖头文件它会直接报错。比如--with-python要求系统有对应的 Python 开发包如果当初装了 Python 但后来卸载了这里就得先补上。报错日志会写得很明确比如checking for Python... no configure: error: Python not found这种时候补齐依赖重新 configure 即可不要为了赶时间把参数删掉因为删掉参数得到的二进制和旧版本不一致后面扩展可能出问题。第三有些选项跟平台相关。如果旧版本支持但你换了一台全新的编译机比如从 CentOS 7 换到了 CentOS 8某些系统库版本不一样会导致行为变化。稳妥起见升级编译最好在原来那台编译机上做如果实在要在新机器上编把结果拷贝过去时至少先跑一遍pg_config对照确认。我有一次就是在升级时自作聪明加了--with-icu结果新二进制在主库上启动了但一个依赖 ICU 排序规则的逻辑复制订阅端因为 ICU 版本差异报错最后还得回退。升级就老老实实跟旧配置保持一致别夹带私货。3.3 编译与安装configure 完成后执行编译make -j 8-j后面的数字建议跟 CPU 核数对齐。如果机器是 4 核-j 8反而可能因为内存不足导致编译中断。编译过程大概 5 到 15 分钟取决于机器性能。接着安装make install这个命令默认会把二进制安装到--prefix指定的目录普通用户如果没权限写/usr/local需要用 sudosudo make install然后一定要进 contrib 目录再编译一次否则 pg_stat_statements 等扩展还是旧版本的cd contrib make -j 8 sudo make install cd ..注意如果 configure 时带了--with-perl、--with-python源码包里对应的 PL/Perl、PL/Python 模块也会在 make install 时被编译安装。若你升级前用的plperl和plpython3u升级后记得实际连上去调用一下。安装完成后验证一下新版本二进制/usr/local/pgsql/bin/postgres --version输出应该变为postgres (PostgreSQL) 12.7同时pg_config --version也一样。3.4 第三方扩展的同步编译除了 PG 自带的 contrib可能还装过第三方扩展。最常见的是postgis、citus、timescaledb、pgrouting等。这些扩展都有独立的源码包它们通常需要针对特定 PG 版本重新编译。以 PostGIS 为例仅示意流程不是让你真在升级时临时编一个 PostGIS正常应该在正式升级前先手工编好tar -xzf postgis-3.1.4.tar.gz cd postgis-3.1.4 ./configure --with-pgconfig/usr/local/pgsql/bin/pg_config make -j 8 sudo make install关键点是--with-pgconfig或者 PostgreSQL 相关的配置参数一定要指向新版本的 pg_config。如果系统里有多个 PG 版本pg_config默认可能指向旧版本这时要显式指定否则编译出来的.so链接的还是旧库。如果某个第三方扩展没有及时适配 PG 12.7或者没有对应版本发布那么升级前最好先查一下它的兼容性矩阵。如果扩展官方明确不兼容你就得考虑这个扩展是否可以暂时停用或者干脆推迟升级。我在一个项目里碰到过这种情况数据库里有个老的postgis版本只支持到 PG 12.4官方更新到支持 12.7 的版本还没发出来。为了升 12.7先要升级 postgis而 postgis 升级本身又要求先把 PG 升上去形成了一个互相卡脖子的循环。最后是先在测试环境里用 12.7 新 postgis 提前做了全链路验证生产再同步操作才顺利解决。所以第三方扩展的兼容性一定要提前确认别等编译完了才发现。4. 切换升级与验证4.1 优雅停库与二进制切换新版本编译安装完成并验证后接下来就是切换。这里建议把所有验证工作在启动新二进制之前做干净。先做一次快速健康检查psql -h localhost -U postgres -c SELECT version();正常的话会输出PostgreSQL 12.2。然后以 fast 模式停库。这里我特别强调尽量用fast不要用immediate/usr/local/pgsql/bin/pg_ctl -D /data/pgdata stop -m fastfast 模式会让 PG 做完已提交事务的清理、把 WAL 刷盘、通知会话断开之后才退出正常情况几秒到几十秒。如果用 immediate相当于直接做崩溃恢复虽然也能起来但没有必要在受控升级里制造这种额外风险。如果这套 PG 是注册为 systemd 服务管理的也可以systemctl stop postgresql或者旧版 init scriptservice postgresql stop停库后确认进程真正结束ps aux | grep postgres如果还有残留进程用pg_ctl status -D /data/pgdata看是个什么状态。别急着重启先查清楚是不是有死锁或慢会话拖住了 shutdown。二进制切换其实在 make install 时已经完成了因为新版本的 postgres 可执行文件已经覆盖了/usr/local/pgsql/bin/postgres。此时你需要注意一个细节如果之前用了软链接方式管理二进制比如/usr/local/pgsql是个软链接指向/usr/local/pgsql-12.2那么这次 make install 安装进去的是 12.2 的目录切软链接指向 12.7 目录才行。检查数据目录里的PG_VERSION文件这是个纯文本文件内容它写的应该是12小版本号不会体现。这个文件没有变化是正常的别看到它还是 12 就以为升级失败。4.2 启动新版本实例启动前先确认postgresql.conf和pg_hba.conf没有在升级过程中被覆盖。如果 make install 时的--prefix目录里恰好包含了一份默认的postgresql.conf.sample它跟你的/data/pgdata数据目录中的配置文件在物理上是两回事一般也不会覆盖但你要是手动把样本文件复制过就属于人为事故了。启动/usr/local/pgsql/bin/pg_ctl -D /data/pgdata start或者systemctl start postgresql启动后立即看日志。日志位置通常在数据目录下的log子目录或者在postgresql.conf里配置了logging_collector指向的位置。重点看有没有这些内容database system was interrupted while in recoveryinvalid resource manager IDcould not access file pg_stat_statementsincompatible library正常升级后启动日志里会有一条LOG: database system was shut down at ... LOG: database system is ready to accept connections如果看到最后一行卡住或者一直循环输出错误说明有问题。先别急着猜测新二进制启动失败时日志会告诉你答案。启动完成后直接用新版本 psql 连上去确认/usr/local/pgsql/bin/psql -h localhost -U postgres -p 5432 -c SHOW server_version;输出应该是server_version ---------------- 12.7到这里核心切换已经算完成了但还不能收工接下来要处理扩展和功能验证。4.3 扩展升级与功能验证切换后最大的动作是扩展升级。前面在数据库里查询到的已安装扩展逐个确认是否需要更新SELECT name, installed_version, default_version FROM pg_available_extensions WHERE installed_version IS NOT NULL AND installed_version ! default_version;如果发现有扩展的已安装版本低于默认版本执行ALTER EXTENSION pg_stat_statements UPDATE;像 PostGIS 这种扩展升级可能涉及ALTER EXTENSION和跑一遍自带的 SQL 升级脚本。建议在测试库上先把这些 SQL 脚本按顺序执行一遍确认没有语法报错和依赖缺失再放进生产执行。扩展升级完成后做几项基础验证连接验证业务账号、只读账号、管理账号分别尝试连接核心功能验证跑几条有代表性的查询比如主键查询、大表聚合、JOIN 查询扩展功能验证如果你用了 pg_stat_statements跑几个查询后看pg_stat_statements_view是否有新记录备份验证起一个pg_dump或者pg_basebackup的测试备份确认备份功能正常如果这库有主从复制升级后要额外关注复制状态。从库的二进制也要同步升到 12.7否则主库和从库版本不一致虽然 PG 12 允许小版本间复制但仍然建议保持两端版本一致避免某些 WAL 行为的细微差异影响同步。可以从库先升再升主库也可以先主后从具体看业务的容忍度。还有一个容易漏的点定时任务或脚本里如果有硬编码/usr/local/pgsql/bin/psql这类路径因为路径没变问题不大。但如果你的运维脚本里有版本判断逻辑比如psql --version等于12.2才执行某个操作升级后版本变了脚本就会走错分支要提前检查脚本里面的版本硬编码。5. 常见问题与排查清单5.1 最容易踩的五个坑这里我把实际操作中见过的最多的坑列出来挨个说清楚。第一configure 参数不一致导致的隐性功能丢失。典型场景旧版本带--with-python新版本不带编译安装完数据库正常启动业务也正常但某个调用 plpython3u 函数的调度任务开始报错原因是新二进制没编译 PL/Python数据库里plpython3u语言根本加载不了。排查SELECT lanname FROM pg_language;对比升级前后列表缺了什么就补什么。最省事的方式还是开头说的升级前把pg_config --configure抠出来升级时原样照抄。第二第三方扩展没重编。比如 PostGIS 数据库里在用的几何类型扩展文件还是 PG 12.2 编译的切换到 12.7 后启动日志出现ERROR: incompatible library或者启动后执行 PostGIS 函数直接报无法加载。解决方法是按扩展自身文档在 12.7 源码下重新编译安装并执行ALTER EXTENSION ... UPDATE。第三编译时内存爆掉。源码编译 PG 特别是开-j参数过高时gcc 会同时开很多编译进程对于 1G 内存的小机器直接 OOM。表现为编译到一半终端卡死或者 gcc 进程被系统杀掉。解决办法是降低-j参数比如make -j 2或者先关掉一部分大并发服务再编译。第四启动时端口被占。如果新版本没有继承--with-pgport而你的旧版本用的是非默认端口新二进制默认监听 5432另一套 PG 或者别的服务占了 5432启动就报 address already in use。这时候pg_ctl start会直接退出日志里是could not bind to address。解决办法是确认postgresql.conf里port参数如果数据目录里的配置文件本来就是自定的端口一般不会受影响否则要用-o -p指定端口启动。第五升级完成后忘记重新编译 contrib。表现为pg_stat_statements在升级前能用升级后查询直接报ERROR: could not open extension control file或者ERROR: could not load library /usr/local/pgsql/lib/pg_stat_statements.so这个因为 make install 只装核心contrib 需要单独cd contrib make install。这也是最容易因为赶进度而漏掉的一步。整理成一张速查表问题现象根因处理方式启动后某些语言扩展不可用configure 参数不一致对照旧参数重新 configure、编译启动时报 incompatible library第三方扩展未重编在新版本下重编扩展并执行 ALTER EXTENSION UPDATE启动报 could not bind address端口冲突检查 postgresql.conf 的 port 配置编译过程中被 OOM 杀掉make -j 参数过大降低并行编译参数扩展控制文件找不到未编译 contrib进入 contrib 目录重新 make install5.2 升级失败后的回滚技巧升级再怎么谨慎依然存在失败的可能。比如新版本启动后一个小时内业务方反馈某个查询性能明显下降或者某个存储过程行为异常。这时候你需要有能力回滚到旧版本而不是干瞪眼。回滚的前提是备份过旧二进制。这个我建议在升级前就做把旧版本的二进制、共享库和扩展文件整体打包比如tar -czf /backup/pg12.2-bin.tar.gz /usr/local/pgsql如果没提前备份二进制已经被覆盖了想从源码重新编译一份 12.2 也是可行的但会多花很多时间不符合快速回滚的要求。回滚的操作顺序和升级正好相反停库pg_ctl stop -m fast解压备份的旧版本二进制覆盖回/usr/local/pgsql注意扩展文件也得覆盖回去因为新版本编译的扩展在旧版二进制下很可能不兼容再启动库确认版本回到 12.2这里有一个很容易忽略的细节升级过程中如果执行了ALTER EXTENSION UPDATE那数据库内部记录的扩展版本已经变了而回滚只恢复了二进制文件扩展元数据和实际物理文件可能不完全匹配。这种情况下数据库可能启动不了或者扩展无法使用。所以最干净的方案是在升级前记录下每个扩展的版本号回滚后如果发现扩展状态异常用DROP EXTENSION再CREATE EXTENSION的方式重建前提是扩展本身的物理文件也回滚到旧版本。如果在生产上已经用了一段升级后的新版本有新的写入数据产生再回滚到旧二进制PG 12 的小版本回滚通常是允许的因为存储格式兼容但 WAL 版本如果在 12.7 中产生了新的类型理论上旧版可能无法识别。这就要求回滚前必须对当前数据目录做一次全量备份以防回滚后数据异常又丢失新写入的数据。总结一句话升级前备份旧版本二进制升级后数据目录再备份一次随时保证自己两条路都能走。5.3 升级后的日志检查与长期观察启动成功后不要急着收工。别忘了 PostgreSQL 的日志是运维判断升级是否真正健康的重要依据。建议至少观察三个日志点第一启动日志里是否出现WARNING级别的提示。比如could not load library这类警告虽然数据库能启动但说明某个扩展加载失败需要处理。第二观察postgresql-%Y-%m-%d.log里面是否有频繁的ERROR或FATAL记录。如果升级后某个统计任务或连接池频繁报错可能是版本变更导致的兼容性问题。第三监控慢查询日志。升级前后跑一遍同样的业务压测或抽样查询对比慢查询的耗时分布。PG 12.2 到 12.7 之间有些查询计划可能因为内部统计方式的微调而发生变化极端情况下会有计划退化表现为某条 SQL 突然从 10ms 变成 1s。遇到这种情况不要慌抓取执行计划对比升级前后的差异必要时用pg_hint_plan固定原计划或者调整统计信息。还有一个长期观察点检查pg_stat_activity里活跃的连接数和事务持续时间。小版本升级一般不会引起连接数异常但如果是第三方库编译不兼容导致某些客户端连接时进程崩溃会在状态里留下大量的idle in transaction这种问题要尽早发现。5.4 系统化之后的升级脚本沉淀升级做过一次之后建议把整个操作流程写成可复用的脚本下一次 12.7 升到 12.9、12.10 时直接改版本号就能用。核心脚本结构如下#!/bin/bash # PostgreSQL 源码小版本升级脚本 # 用法: ./pg_upgrade_minor.sh 新版本号 旧版本软件目录 数据目录 set -euo pipefail NEW_VERSION${1:?需要指定新版本号比如 12.7} PG_PREFIX${2:?需要指定软件目录比如 /usr/local/pgsql} PGDATA${3:?需要指定数据目录比如 /data/pgdata} OLD_VERSION$(pg_config --version | awk {print $2}) echo 当前版本: $OLD_VERSION, 准备升级到: $NEW_VERSION # 1. 备份关键信息 pg_config --configure /tmp/pg-config-args-${NEW_VERSION}.txt # 2. 备份旧二进制 tar -czf /backup/bin-backup-${OLD_VERSION}.tar.gz $PG_PREFIX # 3. 下载源码 cd /tmp wget https://ftp.postgresql.org/pub/source/v${NEW_VERSION}/postgresql-${NEW_VERSION}.tar.bz2 tar -xjf postgresql-${NEW_VERSION}.tar.bz2 cd postgresql-${NEW_VERSION} # 4. 使用旧版本相同的 configure 参数 CONFIG_ARGS$(grep ^configure /tmp/pg-config-args-${NEW_VERSION}.txt | sed s/^configure // | sed s/^//; s/$//) sh -c ./configure $CONFIG_ARGS # 5. 编译安装 make -j $(nproc) sudo make install cd contrib sudo make install cd .. # 6. 停库切换 pg_ctl -D $PGDATA stop -m fast pg_ctl -D $PGDATA start echo 升级完成当前版本: pg_config --version这个脚本里的 configure 参数解析逻辑pg_config --configure输出里带单引号直接传给sh -c时要注意引号处理我这个写法在多数发行版上没问题但如果你遇到解析错误最靠谱的方式还是把参数手动复制过去别过度依赖脚本的字符串解析。脚本沉淀下来之后整个流程的维护成本就低了。你可以在测试环境先把这个脚本跑一遍确认没问题后再在生产执行这也是我比较推荐的做法。6. 写在最后的经验之谈源码编译环境下的 PG 小版本升级说到底拼的是“细节一致性”。版本号变了但数据行为、编译参数、扩展体系都必须保持连贯任何一环脱节数据库可能都能启动但业务侧的某个隐蔽功能可能已经悄悄不对劲了。我个人的经验是升级过程中宁可慢一点把pg_config --configure的输出、扩展版本清单、关键 SQL 的运行结果都留档保存也不要为了抢时间跳步。另外升级后的验证期不要只盯着数据库本身要多和业务方确认。数据库层面心跳正常、连接正常、查询正常不等于业务真正无感。我在一次升级后数据库一切指标都好看但业务方报告某个报表查询比平时慢了十倍最后发现是统计信息在升级后的第一次手动 analyze 之前没跑优化器生成了次优计划。后来我在升级脚本里加了一步启动后自动对核心表执行ANALYZE从此就没再遇到这种问题了。最后再分享一个小技巧如果条件允许升级前先在测试环境把整套流程走一遍记录每一步的实际耗时。源码编译安装 12.7 这个过程本身可能只要 10 到 20 分钟但停库窗口、扩展升级、验证工作加起来完整的一次升级可能需要预留 1 到 2 小时。把时间预算做足比什么都重要。小版本升级不是高危操作但也不能掉以轻心尤其是生产环境一次从容的升级胜过十次紧急的补救。 
长河君 · 2026/10/20 8:14:07 · 阅读 1.2k PostgreSQL源码编译环境下小版本升级实战：从12.2到12.7
1. 升级思路与方案选型1.1 为什么非得做这个小版本升级先聊场景。某个生产环境的 PostgreSQL 还在跑 12.2版本有点老了12.2 到 12.7 之间修了不少东西包括一些复制槽位的稳定性修复、vacuum 相关的性能问题、还有索引扫描的边界情况不升确实有点睡不着觉。而当时这套库是用源码编译方式装到指定目录的既没有用官方仓库的 RPM也没有用 apt数据目录、配置文件、扩展都散落在自己的目录体系里。这种环境最大的问题在于不能像 RPM 安装那样直接yum update或dnf update一把梭必须手动下载新版本源码、重新编译安装再做一次受控的重启切换。小版本升级的逻辑其实很朴素12.x 系列内部的数据目录格式和系统表结构在小版本之间不会变更所以不需要走 pg_upgrade 那套迁移流程更不需要 dump 再 restore。核心动作就两个——把旧的二进制文件替换成新版本二进制然后以新二进制启动原来的数据目录。听起来简单实际操作里坑不少尤其是源码编译环境下编译参数不一致、第三方扩展没跟着重编、二进制和动态库版本不匹配这些都会让你在启动的那一刻收到莫名其妙的服务启动失败。这篇文章不是从零教你编译安装 PG 的而是偏重“升级”这件事。我假设你已经有一台跑着 PG 12.2 的服务器PG 是源码编译装在/usr/local/pgsql之类的目录下现在要把它升到 12.7。如果你还在用 RPM 或者云数据库托管那这篇文章的操作思路可以参考但具体命令不完全适用。1.2 源码编译升级与 RPM 升级的差异用 RPM 或 apt 安装的 PG二进制统一放在发行版约定好的路径里比如/usr/pgsql-12/bin升级时包管理器会自动帮你处理二进制覆盖、服务脚本更新、依赖校验这些事。源码编译安装则是你自己掌控一切路径和编译选项升级时没有一个包管理器替你做依赖检查容易漏掉的就是 contrib 模块和第三方扩展。还有一点RPM 包升级时一般会顺手帮你在postgresql12-upgrade这类脚本里做服务停止和启动的编排源码编译升级则完全要自己执行自己停库fast 模式自己确认编译参数自己编译安装自己启动并验证听起来多但每步都清楚可控这也是我推荐源码编译环境尽量保持“同一套参数从一而终”的原因。若你最初编译时开了--with-perl、--with-python、--with-pgport升级时这些选项一个都不能少不然新二进制和你之前装的那些扩展、语言绑定就全对不上号了。很多人不看pg_config --configure的输出直接./configure一把默认参数就 make install结果升级完发现端口从 5432 变了PL/Python 不可用了之前能用的某个扩展报错找不到依赖库这种“升级成功但业务已经受影响了”的情况其实比升级失败更让人头疼因为你得逐项排查是哪个编译特性丢了。1.3 小版本升级与大版本迁移的本质区别有必要把这两件事彻底分开。PG 12.2 升到 12.7 属于小版本升级官方文档里明确说这种升级不需要 dump/restore也不需要 pg_upgrade。只要新版本的 PostgreSQL 在启动时遇到比它更老的PG_VERSION文件它会自动做兼容处理继续沿用原有数据目录。但如果是 PG 12 升到 PG 13 或更高版本那就是大版本升级需要走 pg_upgrade 或者逻辑导出导入因为系统表结构变了、数据文件布局变了甚至一些函数的内部实现都变了同一个数据目录不能直接让新版本认领。我在实际工作里见过有人拿小版本升级的思路去搞大版本升级直接把 PG 14 的二进制指到 PG 12 的数据目录上启动后日志里报了一堆database files are incompatible with server的错误。这就是没搞清“小版本升级到底在升什么”。小版本升级还有一层特殊价值它是在同一个大版本号内做 bugfix因此业务影响面极小。比如 12.2 和 12.7 之间官方 release notes 里列的修复项包括逻辑复制解码的崩溃问题、GIN 索引 vacuum 时的空间回收效率、以及并行查询中的某些死锁情况这些都是运行时行为层面的修补不会改变 SQL 语义也不改变存储格式。所以你完全可以在业务低峰期完成升级不需要走迁移窗口部署的复杂度和风险都比大版本升级低一个量级。2. 升级前的准备工作2.1 盘点现有编译参数这是整个升级流程里我认为最不能省的一步。源码编译安装的 PG编译时敲了哪些选项直接决定了新版本二进制要复刻哪些配置。获取方法很简单/usr/local/pgsql/bin/pg_config --configure输出长这样configure --prefix/usr/local/pgsql --with-pgport5432 --with-perl --with-python --with-openssl --with-libxml --with-libxslt你把这个输出原封不动记下来后面 configure 的时候直接照抄别自己发挥。比如原来没开--with-python升级时突然加了这不叫增强这叫给自己挖坑——因为 PG 检测到新的 configure 选项后会在编译期编译对应模块但你可能根本没装好 Python 的开发头文件结果是编译直接中断或者编译过了但运行时加载失败。还有几个容易忽略的--with-pgport如果原来设了非默认端口比如 15432升级时忘了带新二进制默认端口就变成 5432启动时端口冲突或者业务拿着 15432 连不上--with-uuidossp如果原来指定了 uuid 生成方式忘了带会让uuid-ossp扩展行为异常--with-icuPG 12 开始支持 ICU 排序规则如果原来开着升级后忘了数据库里的COLLATE规则可能受影响建议把 pg_config 的输出保存成一个文件比如/root/pg12-configure-args.txt升级完新版本后对比一下。2.2 数据目录与配置备份就算小版本升级官方说风险低备份这条红线不能碰。因为一旦编译出来的二进制有问题或者启动后数据文件报错你还得把旧二进制恢复回去。备份至少做两层第一层是文件级备份把数据目录的配置文件、pg_hba.conf、postgresql.conf、pg_ident.conf复制一份到独立目录mkdir -p /backup/pg-conf-backup cp $PGDATA/postgresql.conf /backup/pg-conf-backup/ cp $PGDATA/pg_hba.conf /backup/pg-conf-backup/ cp $PGDATA/pg_ident.conf /backup/pg-conf-backup/第二层是物理备份用 pg_basebackup 做一个全量在线备份这样可以随时回滚到升级前的状态pg_basebackup -h localhost -U postgres -D /backup/pg12-full-backup -Ft -z -P这里用的-Ft表示 tar 格式输出-z表示压缩-P显示进度。备份完成后务必验证一下检查 tar 文件能否正常解压最好在另一台机器上恢复出来做一次只读启动验证。这一步能发现备份文件是否有效而不是等出事了才知道备份不可用。如果数据库特别大备份时间很长业务上又不允许长时间锁表那么 pg_basebackup 的在线备份机制不会阻塞正常读写它基于 WAL 的复制原理工作所以可以放心在生产环境执行。但要注意如果开了复制槽replication slotpg_basebackup 默认不会自动备份复制槽信息如果这是一套主从环境升级主库前最好确认从库的状态和槽位情况。2.3 扩展与依赖项摸底源码编译环境里最容易漏掉的是 contrib 模块和第三方扩展。PostgreSQL 12.2 安装时你大概率执行过进入 contrib 目录再 make install 的操作。比如pg_stat_statements、pgcrypto、uuid-ossp、btree_gist这些都属于 contrib 范畴。在升级前先盘点当前数据库里到底用了哪些扩展SELECT name, default_version, installed_version FROM pg_available_extensions WHERE installed_version IS NOT NULL;记录下来升级完二进制之后对应的.so文件和 SQL 脚本也必须更新。PostgreSQL 12.7 的源码包里的 contrib 目录会附带对应的扩展 SQL 和动态库你需要在 make install 之后进入旧的扩展目录重新编译安装。另外检查一下是否装了pgbouncer、repmgr这类外部工具它们可能会链接 PG 的 libpq 库。升级后如果只替换了 PostgreSQL 服务端二进制没动 libpq通常没太大影响但如果你编译时改了--prefix把新版 PG 安装到了新目录那么旧的外部工具可能还在链接旧 libpq这种情况一般建议顺手把 libpq 相关软链接也更新一下。最后检查编译所需依赖是否齐全尤其是否还保留着源码编译工具链gcc / makereadline-dev / libreadline-devzlib1g-devbison / flex编译 PG 源码必需openssl-dev如果 configure 里有 --with-openssl很多服务器在装完 PG 之后会顺手清理编译依赖升级时才发现没 gcc临时装又要走一遍软件源。所以这一步提前做能省半天。3. 源码编译安装新版本3.1 下载源码与完整性校验升级用的源码包地址官方是https://ftp.postgresql.org/pub/source/v12.7/postgresql-12.7.tar.bz2下载之后建议校验一下压缩包完整性。官方在源码包旁边提供了对应的.sha256或.md5文件SHA256$(curl -s https://ftp.postgresql.org/pub/source/v12.7/postgresql-12.7.tar.bz2.sha256 | awk {print $1}) echo ${SHA256} postgresql-12.7.tar.bz2 | sha256sum -c -校验通过再解压。这一步很多人忽略但下载源偶尔会有 CDN 断裂或代理缓存导致包损坏的情况如果解压时报错或者编译时出现奇怪的语法错误先回头检查包是不是完整。解压tar -xjf postgresql-12.7.tar.bz2 cd postgresql-12.73.2 configure 参数一致性详解这是整个升级流程中真正的“胜负手”。前面你通过 pg_config 拿到了旧版本的 configure 参数现在直接照着跑./configure --prefix/usr/local/pgsql --with-pgport5432 --with-perl --with-python --with-openssl --with-libxml --with-libxslt注意几点第一--prefix一定不要改。如果你之前把 PG 装在/usr/local/pgsql升级时也必须是这个目录。否则你会把新版本装到一个全新的位置老位置还是原来的 12.2业务连的 psql 和 server 还是旧版本等于没有升级。第二如果源码包里的 configure 检测不到某个依赖头文件它会直接报错。比如--with-python要求系统有对应的 Python 开发包如果当初装了 Python 但后来卸载了这里就得先补上。报错日志会写得很明确比如checking for Python... no configure: error: Python not found这种时候补齐依赖重新 configure 即可不要为了赶时间把参数删掉因为删掉参数得到的二进制和旧版本不一致后面扩展可能出问题。第三有些选项跟平台相关。如果旧版本支持但你换了一台全新的编译机比如从 CentOS 7 换到了 CentOS 8某些系统库版本不一样会导致行为变化。稳妥起见升级编译最好在原来那台编译机上做如果实在要在新机器上编把结果拷贝过去时至少先跑一遍pg_config对照确认。我有一次就是在升级时自作聪明加了--with-icu结果新二进制在主库上启动了但一个依赖 ICU 排序规则的逻辑复制订阅端因为 ICU 版本差异报错最后还得回退。升级就老老实实跟旧配置保持一致别夹带私货。3.3 编译与安装configure 完成后执行编译make -j 8-j后面的数字建议跟 CPU 核数对齐。如果机器是 4 核-j 8反而可能因为内存不足导致编译中断。编译过程大概 5 到 15 分钟取决于机器性能。接着安装make install这个命令默认会把二进制安装到--prefix指定的目录普通用户如果没权限写/usr/local需要用 sudosudo make install然后一定要进 contrib 目录再编译一次否则 pg_stat_statements 等扩展还是旧版本的cd contrib make -j 8 sudo make install cd ..注意如果 configure 时带了--with-perl、--with-python源码包里对应的 PL/Perl、PL/Python 模块也会在 make install 时被编译安装。若你升级前用的plperl和plpython3u升级后记得实际连上去调用一下。安装完成后验证一下新版本二进制/usr/local/pgsql/bin/postgres --version输出应该变为postgres (PostgreSQL) 12.7同时pg_config --version也一样。3.4 第三方扩展的同步编译除了 PG 自带的 contrib可能还装过第三方扩展。最常见的是postgis、citus、timescaledb、pgrouting等。这些扩展都有独立的源码包它们通常需要针对特定 PG 版本重新编译。以 PostGIS 为例仅示意流程不是让你真在升级时临时编一个 PostGIS正常应该在正式升级前先手工编好tar -xzf postgis-3.1.4.tar.gz cd postgis-3.1.4 ./configure --with-pgconfig/usr/local/pgsql/bin/pg_config make -j 8 sudo make install关键点是--with-pgconfig或者 PostgreSQL 相关的配置参数一定要指向新版本的 pg_config。如果系统里有多个 PG 版本pg_config默认可能指向旧版本这时要显式指定否则编译出来的.so链接的还是旧库。如果某个第三方扩展没有及时适配 PG 12.7或者没有对应版本发布那么升级前最好先查一下它的兼容性矩阵。如果扩展官方明确不兼容你就得考虑这个扩展是否可以暂时停用或者干脆推迟升级。我在一个项目里碰到过这种情况数据库里有个老的postgis版本只支持到 PG 12.4官方更新到支持 12.7 的版本还没发出来。为了升 12.7先要升级 postgis而 postgis 升级本身又要求先把 PG 升上去形成了一个互相卡脖子的循环。最后是先在测试环境里用 12.7 新 postgis 提前做了全链路验证生产再同步操作才顺利解决。所以第三方扩展的兼容性一定要提前确认别等编译完了才发现。4. 切换升级与验证4.1 优雅停库与二进制切换新版本编译安装完成并验证后接下来就是切换。这里建议把所有验证工作在启动新二进制之前做干净。先做一次快速健康检查psql -h localhost -U postgres -c SELECT version();正常的话会输出PostgreSQL 12.2。然后以 fast 模式停库。这里我特别强调尽量用fast不要用immediate/usr/local/pgsql/bin/pg_ctl -D /data/pgdata stop -m fastfast 模式会让 PG 做完已提交事务的清理、把 WAL 刷盘、通知会话断开之后才退出正常情况几秒到几十秒。如果用 immediate相当于直接做崩溃恢复虽然也能起来但没有必要在受控升级里制造这种额外风险。如果这套 PG 是注册为 systemd 服务管理的也可以systemctl stop postgresql或者旧版 init scriptservice postgresql stop停库后确认进程真正结束ps aux | grep postgres如果还有残留进程用pg_ctl status -D /data/pgdata看是个什么状态。别急着重启先查清楚是不是有死锁或慢会话拖住了 shutdown。二进制切换其实在 make install 时已经完成了因为新版本的 postgres 可执行文件已经覆盖了/usr/local/pgsql/bin/postgres。此时你需要注意一个细节如果之前用了软链接方式管理二进制比如/usr/local/pgsql是个软链接指向/usr/local/pgsql-12.2那么这次 make install 安装进去的是 12.2 的目录切软链接指向 12.7 目录才行。检查数据目录里的PG_VERSION文件这是个纯文本文件内容它写的应该是12小版本号不会体现。这个文件没有变化是正常的别看到它还是 12 就以为升级失败。4.2 启动新版本实例启动前先确认postgresql.conf和pg_hba.conf没有在升级过程中被覆盖。如果 make install 时的--prefix目录里恰好包含了一份默认的postgresql.conf.sample它跟你的/data/pgdata数据目录中的配置文件在物理上是两回事一般也不会覆盖但你要是手动把样本文件复制过就属于人为事故了。启动/usr/local/pgsql/bin/pg_ctl -D /data/pgdata start或者systemctl start postgresql启动后立即看日志。日志位置通常在数据目录下的log子目录或者在postgresql.conf里配置了logging_collector指向的位置。重点看有没有这些内容database system was interrupted while in recoveryinvalid resource manager IDcould not access file pg_stat_statementsincompatible library正常升级后启动日志里会有一条LOG: database system was shut down at ... LOG: database system is ready to accept connections如果看到最后一行卡住或者一直循环输出错误说明有问题。先别急着猜测新二进制启动失败时日志会告诉你答案。启动完成后直接用新版本 psql 连上去确认/usr/local/pgsql/bin/psql -h localhost -U postgres -p 5432 -c SHOW server_version;输出应该是server_version ---------------- 12.7到这里核心切换已经算完成了但还不能收工接下来要处理扩展和功能验证。4.3 扩展升级与功能验证切换后最大的动作是扩展升级。前面在数据库里查询到的已安装扩展逐个确认是否需要更新SELECT name, installed_version, default_version FROM pg_available_extensions WHERE installed_version IS NOT NULL AND installed_version ! default_version;如果发现有扩展的已安装版本低于默认版本执行ALTER EXTENSION pg_stat_statements UPDATE;像 PostGIS 这种扩展升级可能涉及ALTER EXTENSION和跑一遍自带的 SQL 升级脚本。建议在测试库上先把这些 SQL 脚本按顺序执行一遍确认没有语法报错和依赖缺失再放进生产执行。扩展升级完成后做几项基础验证连接验证业务账号、只读账号、管理账号分别尝试连接核心功能验证跑几条有代表性的查询比如主键查询、大表聚合、JOIN 查询扩展功能验证如果你用了 pg_stat_statements跑几个查询后看pg_stat_statements_view是否有新记录备份验证起一个pg_dump或者pg_basebackup的测试备份确认备份功能正常如果这库有主从复制升级后要额外关注复制状态。从库的二进制也要同步升到 12.7否则主库和从库版本不一致虽然 PG 12 允许小版本间复制但仍然建议保持两端版本一致避免某些 WAL 行为的细微差异影响同步。可以从库先升再升主库也可以先主后从具体看业务的容忍度。还有一个容易漏的点定时任务或脚本里如果有硬编码/usr/local/pgsql/bin/psql这类路径因为路径没变问题不大。但如果你的运维脚本里有版本判断逻辑比如psql --version等于12.2才执行某个操作升级后版本变了脚本就会走错分支要提前检查脚本里面的版本硬编码。5. 常见问题与排查清单5.1 最容易踩的五个坑这里我把实际操作中见过的最多的坑列出来挨个说清楚。第一configure 参数不一致导致的隐性功能丢失。典型场景旧版本带--with-python新版本不带编译安装完数据库正常启动业务也正常但某个调用 plpython3u 函数的调度任务开始报错原因是新二进制没编译 PL/Python数据库里plpython3u语言根本加载不了。排查SELECT lanname FROM pg_language;对比升级前后列表缺了什么就补什么。最省事的方式还是开头说的升级前把pg_config --configure抠出来升级时原样照抄。第二第三方扩展没重编。比如 PostGIS 数据库里在用的几何类型扩展文件还是 PG 12.2 编译的切换到 12.7 后启动日志出现ERROR: incompatible library或者启动后执行 PostGIS 函数直接报无法加载。解决方法是按扩展自身文档在 12.7 源码下重新编译安装并执行ALTER EXTENSION ... UPDATE。第三编译时内存爆掉。源码编译 PG 特别是开-j参数过高时gcc 会同时开很多编译进程对于 1G 内存的小机器直接 OOM。表现为编译到一半终端卡死或者 gcc 进程被系统杀掉。解决办法是降低-j参数比如make -j 2或者先关掉一部分大并发服务再编译。第四启动时端口被占。如果新版本没有继承--with-pgport而你的旧版本用的是非默认端口新二进制默认监听 5432另一套 PG 或者别的服务占了 5432启动就报 address already in use。这时候pg_ctl start会直接退出日志里是could not bind to address。解决办法是确认postgresql.conf里port参数如果数据目录里的配置文件本来就是自定的端口一般不会受影响否则要用-o -p指定端口启动。第五升级完成后忘记重新编译 contrib。表现为pg_stat_statements在升级前能用升级后查询直接报ERROR: could not open extension control file或者ERROR: could not load library /usr/local/pgsql/lib/pg_stat_statements.so这个因为 make install 只装核心contrib 需要单独cd contrib make install。这也是最容易因为赶进度而漏掉的一步。整理成一张速查表问题现象根因处理方式启动后某些语言扩展不可用configure 参数不一致对照旧参数重新 configure、编译启动时报 incompatible library第三方扩展未重编在新版本下重编扩展并执行 ALTER EXTENSION UPDATE启动报 could not bind address端口冲突检查 postgresql.conf 的 port 配置编译过程中被 OOM 杀掉make -j 参数过大降低并行编译参数扩展控制文件找不到未编译 contrib进入 contrib 目录重新 make install5.2 升级失败后的回滚技巧升级再怎么谨慎依然存在失败的可能。比如新版本启动后一个小时内业务方反馈某个查询性能明显下降或者某个存储过程行为异常。这时候你需要有能力回滚到旧版本而不是干瞪眼。回滚的前提是备份过旧二进制。这个我建议在升级前就做把旧版本的二进制、共享库和扩展文件整体打包比如tar -czf /backup/pg12.2-bin.tar.gz /usr/local/pgsql如果没提前备份二进制已经被覆盖了想从源码重新编译一份 12.2 也是可行的但会多花很多时间不符合快速回滚的要求。回滚的操作顺序和升级正好相反停库pg_ctl stop -m fast解压备份的旧版本二进制覆盖回/usr/local/pgsql注意扩展文件也得覆盖回去因为新版本编译的扩展在旧版二进制下很可能不兼容再启动库确认版本回到 12.2这里有一个很容易忽略的细节升级过程中如果执行了ALTER EXTENSION UPDATE那数据库内部记录的扩展版本已经变了而回滚只恢复了二进制文件扩展元数据和实际物理文件可能不完全匹配。这种情况下数据库可能启动不了或者扩展无法使用。所以最干净的方案是在升级前记录下每个扩展的版本号回滚后如果发现扩展状态异常用DROP EXTENSION再CREATE EXTENSION的方式重建前提是扩展本身的物理文件也回滚到旧版本。如果在生产上已经用了一段升级后的新版本有新的写入数据产生再回滚到旧二进制PG 12 的小版本回滚通常是允许的因为存储格式兼容但 WAL 版本如果在 12.7 中产生了新的类型理论上旧版可能无法识别。这就要求回滚前必须对当前数据目录做一次全量备份以防回滚后数据异常又丢失新写入的数据。总结一句话升级前备份旧版本二进制升级后数据目录再备份一次随时保证自己两条路都能走。5.3 升级后的日志检查与长期观察启动成功后不要急着收工。别忘了 PostgreSQL 的日志是运维判断升级是否真正健康的重要依据。建议至少观察三个日志点第一启动日志里是否出现WARNING级别的提示。比如could not load library这类警告虽然数据库能启动但说明某个扩展加载失败需要处理。第二观察postgresql-%Y-%m-%d.log里面是否有频繁的ERROR或FATAL记录。如果升级后某个统计任务或连接池频繁报错可能是版本变更导致的兼容性问题。第三监控慢查询日志。升级前后跑一遍同样的业务压测或抽样查询对比慢查询的耗时分布。PG 12.2 到 12.7 之间有些查询计划可能因为内部统计方式的微调而发生变化极端情况下会有计划退化表现为某条 SQL 突然从 10ms 变成 1s。遇到这种情况不要慌抓取执行计划对比升级前后的差异必要时用pg_hint_plan固定原计划或者调整统计信息。还有一个长期观察点检查pg_stat_activity里活跃的连接数和事务持续时间。小版本升级一般不会引起连接数异常但如果是第三方库编译不兼容导致某些客户端连接时进程崩溃会在状态里留下大量的idle in transaction这种问题要尽早发现。5.4 系统化之后的升级脚本沉淀升级做过一次之后建议把整个操作流程写成可复用的脚本下一次 12.7 升到 12.9、12.10 时直接改版本号就能用。核心脚本结构如下#!/bin/bash # PostgreSQL 源码小版本升级脚本 # 用法: ./pg_upgrade_minor.sh 新版本号 旧版本软件目录 数据目录 set -euo pipefail NEW_VERSION${1:?需要指定新版本号比如 12.7} PG_PREFIX${2:?需要指定软件目录比如 /usr/local/pgsql} PGDATA${3:?需要指定数据目录比如 /data/pgdata} OLD_VERSION$(pg_config --version | awk {print $2}) echo 当前版本: $OLD_VERSION, 准备升级到: $NEW_VERSION # 1. 备份关键信息 pg_config --configure /tmp/pg-config-args-${NEW_VERSION}.txt # 2. 备份旧二进制 tar -czf /backup/bin-backup-${OLD_VERSION}.tar.gz $PG_PREFIX # 3. 下载源码 cd /tmp wget https://ftp.postgresql.org/pub/source/v${NEW_VERSION}/postgresql-${NEW_VERSION}.tar.bz2 tar -xjf postgresql-${NEW_VERSION}.tar.bz2 cd postgresql-${NEW_VERSION} # 4. 使用旧版本相同的 configure 参数 CONFIG_ARGS$(grep ^configure /tmp/pg-config-args-${NEW_VERSION}.txt | sed s/^configure // | sed s/^//; s/$//) sh -c ./configure $CONFIG_ARGS # 5. 编译安装 make -j $(nproc) sudo make install cd contrib sudo make install cd .. # 6. 停库切换 pg_ctl -D $PGDATA stop -m fast pg_ctl -D $PGDATA start echo 升级完成当前版本: pg_config --version这个脚本里的 configure 参数解析逻辑pg_config --configure输出里带单引号直接传给sh -c时要注意引号处理我这个写法在多数发行版上没问题但如果你遇到解析错误最靠谱的方式还是把参数手动复制过去别过度依赖脚本的字符串解析。脚本沉淀下来之后整个流程的维护成本就低了。你可以在测试环境先把这个脚本跑一遍确认没问题后再在生产执行这也是我比较推荐的做法。6. 写在最后的经验之谈源码编译环境下的 PG 小版本升级说到底拼的是“细节一致性”。版本号变了但数据行为、编译参数、扩展体系都必须保持连贯任何一环脱节数据库可能都能启动但业务侧的某个隐蔽功能可能已经悄悄不对劲了。我个人的经验是升级过程中宁可慢一点把pg_config --configure的输出、扩展版本清单、关键 SQL 的运行结果都留档保存也不要为了抢时间跳步。另外升级后的验证期不要只盯着数据库本身要多和业务方确认。数据库层面心跳正常、连接正常、查询正常不等于业务真正无感。我在一次升级后数据库一切指标都好看但业务方报告某个报表查询比平时慢了十倍最后发现是统计信息在升级后的第一次手动 analyze 之前没跑优化器生成了次优计划。后来我在升级脚本里加了一步启动后自动对核心表执行ANALYZE从此就没再遇到这种问题了。最后再分享一个小技巧如果条件允许升级前先在测试环境把整套流程走一遍记录每一步的实际耗时。源码编译安装 12.7 这个过程本身可能只要 10 到 20 分钟但停库窗口、扩展升级、验证工作加起来完整的一次升级可能需要预留 1 到 2 小时。把时间预算做足比什么都重要。小版本升级不是高危操作但也不能掉以轻心尤其是生产环境一次从容的升级胜过十次紧急的补救。