Jeremy Schneider：Postgres 18.7 的 Debian 与 Red Hat 打包者为你保驾护航
内容提要
PostgreSQL 18.7 小版本更新破坏了 ABI 兼容性。Debian 和 RPM 打包已加入版本依赖保护，安装新扩展时会因要求更高版本而失败，从而避免混用不兼容版本。Kubernetes 用户若使用 CNPG 扩展目录可自动获得匹配版本，但手动固定镜像摘要的用户需自行确保兼容。最需警惕的是从源码自行构建数据库和扩展的用户，应尽快处理此更新。
延伸解读
包管理器如何阻止不兼容安装
文章用具体命令展示了保护机制：在 Debian 上，若 postgresql-18 被 hold 在 18.6，安装 postgresql-18-cron 会因依赖要求 postgresql-18 (> 18.7) 而失败；在 Rocky 上，用 --exclude 排除 postgresql18* 后安装 pg_cron_18 也会因 postgresql18-libs >= 18.7 无法满足而失败。这说明打包系统通过版本依赖把不兼容组合挡在安装阶段，而不是等到运行时才暴露问题。
Kubernetes 用户的两种处境
文章区分了 Kubernetes 上两类用户。使用 CNPG 扩展目录的用户基本被覆盖，因为目录是滚动发布，已确保核心 Postgres 和扩展都是最新版本，能自动获得匹配组合。但若手动固定扩展容器摘要或版本、且与 Postgres 服务器版本独立选择，则兼容性需自行保证。此外，直接用 Debian 包构建自定义镜像的用户，只要构建成功就说明版本组合正确。
源码构建者风险最高
文章明确指出，最需要警惕的是不使用打包生态、从源码构建并安装扩展或数据库的用户。对这类人，包管理器的版本依赖保护不起作用，ABI 不兼容问题不会被自动拦截。若自己管理 Postgres 生态代码的构建或 CI，作者建议下周就应着手处理这次小版本更新，而不是依赖系统包管理器兜底。
Q&A
PostgreSQL 18.7 小版本更新破坏了 ABI 兼容性，Debian 和 RPM 打包做了什么保护？
Debian 和 RPM 打包都加入了版本依赖保护：安装新扩展时会要求 PostgreSQL 版本高于 18.7，如果当前版本是 18.6 或更低，安装会失败，从而避免混用不兼容的版本。
在 Debian 上如何临时阻止 PostgreSQL 升级，以便安全安装扩展？
可以使用 apt-mark hold postgresql-18 阻止升级，然后安装扩展；需要升级时再执行 apt-mark unhold postgresql-18 并安装扩展，系统会自动升级 PostgreSQL 到 18.7。
在 Rocky Linux 上安装 pg_cron 扩展时，如何避免意外升级 PostgreSQL？
可以使用 dnf install -y --exclude='postgresql18*' pg_cron_18 来阻止 PostgreSQL 升级，此时安装会因依赖不满足而失败；若允许升级，直接运行 dnf install -y pg_cron_18 即可，系统会自动升级 PostgreSQL 到 18.7。
Kubernetes 用户使用 CloudNativePG 扩展目录时，如何确保扩展与 PostgreSQL 版本兼容？
如果使用 CNPG 扩展目录，由于目录是滚动更新的，会自动包含最新版本的 PostgreSQL 和扩展，因此总是兼容的。但如果手动固定扩展容器镜像的摘要或版本，则需要自行确保与 PostgreSQL 服务器版本兼容。
哪些用户最需要警惕 PostgreSQL 18.7 的 ABI 兼容性问题？
最需要警惕的是那些不使用打包生态系统、从源码自行构建和安装扩展（或数据库）的用户。他们需要尽快处理这次小版本更新，确保扩展与数据库版本兼容。
PostgreSQL 18.7 更新后，如果我不立即升级数据库，下周安装新扩展会有什么后果？
如果下周安装新扩展，打包系统会尝试拉取最新版本的扩展，但由于版本依赖保护，安装会失败，并提示需要更高版本的 PostgreSQL。这可以防止你意外混用不兼容的版本。
