PGDG RPM 仓库配置变简单了：从网页选择到可复制自动化

预计阅读时间：8 分钟

PGDG 的 YUM 与 Zypper RPM 仓库入口完成了重新设计。过去，管理员往往需要在多层目录和说明页面之间来回确认发行版、系统版本、CPU 架构和 PostgreSQL 主版本；现在，这些条件可以直接在首页选择，页面随即生成可复制的安装指令。

这次变化不只是“页面更好看”。它减少了选错仓库的概率，也让团队更容易把一组确定的仓库配置分享给同事，或接入安装脚本和自动化平台。

四个选项决定最终安装指令

新的选择流程围绕四项信息展开：

操作系统：例如 RHEL 兼容发行版或 openSUSE/SLES。
系统版本：仓库元数据和 RPM 依赖需要与系统大版本匹配。
CPU 架构：常见的是 x86_64，也可能是其他受支持架构。
PostgreSQL 版本：决定后续安装的软件包名、二进制目录和服务初始化命令。

完成选择后，页面会显示可以复制粘贴的指令。这比从旧文档中手工替换版本号更可靠，尤其适合同时维护多套操作系统的团队。

实际使用时，不要只看命令中是否出现了目标 PostgreSQL 版本，还应核对仓库 RPM 对应的系统大版本和架构。例如，EL 9 的仓库配置不应该直接复用到 EL 8，x86_64 的选择结果也不应未经检查就放进 ARM 主机的初始化脚本。

“复制链接”让配置可以交接和复现

页面新增的“复制链接”能力可以保留或定制当前选择。这个链接适合用于：

放进内部安装文档，让值班人员打开后得到相同选项；
附在变更单或工单中，记录仓库配置是如何生成的；
在博客、Runbook 或镜像构建说明中共享；
作为自动化系统的输入之一，生成或校验仓库安装步骤。

这里需要区分两类内容：选择页面链接适合表达配置意图，仓库 RPM 地址和安装命令才是部署过程真正执行的输入。如果自动化系统要长期稳定运行，建议把页面生成的仓库 RPM 地址保存为显式变量，而不是依赖脆弱的 HTML 抓取规则。

可以这样实践：把生成结果放进 EL 9 安装脚本

下面是一个可改造的 Bash 示例，假设目标是全新的 EL 9 兼容系统，并准备安装 PostgreSQL 16。运行前，需要在 PGDG 页面完成选择，然后把生成指令中的仓库 RPM 地址填入 REPO_RPM_URL。

#!/usr/bin/env bash
set -euo pipefail

# 修改为选择页面生成的仓库 RPM 地址。
export REPO_RPM_URL="https://example.invalid/replace-with-generated-pgdg-repo.rpm"
export PG_MAJOR="16"

if [[ "$REPO_RPM_URL" == *"example.invalid"* ]]; then
  echo "请先把 REPO_RPM_URL 替换为 PGDG 页面生成的实际地址" >&2
  exit 1
fi

sudo dnf install -y "$REPO_RPM_URL"

# 在提供 AppStream 模块的系统上，避免系统模块遮蔽 PGDG 软件包。
if dnf -q module list postgresql >/dev/null 2>&1; then
  sudo dnf -qy module disable postgresql
fi

sudo dnf install -y \
  "postgresql${PG_MAJOR}" \
  "postgresql${PG_MAJOR}-server"

# 仅适用于尚未初始化的数据目录。
sudo "/usr/pgsql-${PG_MAJOR}/bin/postgresql-${PG_MAJOR}-setup" initdb
sudo systemctl enable --now "postgresql-${PG_MAJOR}"

sudo systemctl --no-pager status "postgresql-${PG_MAJOR}"

脚本故意没有硬编码真实仓库地址：应当以选择页面当前生成的结果为准，避免示例随着发行版生命周期或仓库布局变化而失效。

如果主机已经存在数据库集群，不要再次执行 initdb。升级现有 PostgreSQL 主版本也不能用“安装新包并覆盖旧包”的方式代替迁移，应单独规划备份、兼容性检查以及 pg_upgrade 或逻辑迁移流程。

对于使用 Zypper 的系统，可以采用相同思路：先在页面中选择准确的 SUSE 系列、版本和架构，再复制页面提供的仓库添加与软件包安装命令，不要把 DNF 示例机械改写成 Zypper 命令。

Extra 与 Non-Free 仓库不应默认全开

新版入口还提供 Extra packages repository 和 Non-Free repository 的简化安装说明。这能减少寻找附加仓库文档的时间，但“更容易启用”并不意味着应该在所有机器上默认启用。

建议按照用途分别管理：

基础 PGDG 仓库：提供目标 PostgreSQL 版本及其主要组件；
Extra 仓库：按实际扩展或工具依赖启用，并记录引入的软件包；
Non-Free 仓库：启用前检查许可证、分发限制和组织合规要求。

在生产环境中，可以将不同仓库拆成独立的配置开关。这样，基础数据库节点不会因为某个临时工具而自动扩大软件来源范围。

落地时检查这几件事

新的 PGDG 页面显著缩短了从“我要安装某个 PostgreSQL 版本”到“拿到正确命令”的路径。要把这种便利转化为可靠部署，还可以遵循以下清单：

明确记录操作系统、系统大版本、架构和 PostgreSQL 主版本；
优先使用页面生成的最新指令，不复制多年前博客里的固定命令；
在自动化中保存明确的仓库地址和版本变量，避免无约束地抓取网页；
先在临时主机或镜像构建流水线中验证仓库元数据和依赖；
Extra 与 Non-Free 仓库按需启用，并纳入许可证与供应链审查；
区分“全新安装”和“现有集群升级”，不要让初始化脚本碰到已有数据目录。

对于偶尔手工安装的开发者，新页面减少了查文档的时间；对于维护基础镜像和批量部署的团队，它更重要的价值则是让仓库选择变得可表达、可分享，也更容易转化为受控的自动化输入。