4. 环境与版本基线核查

环境与版本基线核查是 PostgreSQL 项目验收交付中最先落地、也最容易被“差不多就行”心态带偏的一环。它的目标不是简单记录几行版本号，而是把一套可运行、可复现、可追责的数据库运行环境固化成一份双方认可的基线。基线一旦确认，后续的性能测试、备份恢复演练、高可用切换验证才有统一的参照物；否则同一套 SQL 在不同环境上跑出不同结果，验收结论就无从谈起。

本节把核查对象拆成八个维度：操作系统、PostgreSQL 版本、扩展、参数、字符集、时区、网络与存储。每个维度都要回答三个问题：当前实际值是什么、期望值是什么、差异是否可接受。下面先给出整体核对关系，再逐项说明核查方法与判断依据。

操作系统与 PostgreSQL 版本

操作系统核查要落到发行版、内核版本和 C 库版本三行信息上。发行版决定软件包来源与生命周期，内核影响大页、IO 调度和网络参数，glibc 版本则可能影响排序规则与本地化行为。建议在验收现场执行：

cat /etc/os-release | head -n 4
uname -r
ldd --version | head -n 1

PostgreSQL 版本核查不能只看 psql --version，因为它可能指向客户端而非服务端。更可靠的方式是连接实例后查询：

SELECT version();
SHOW server_version;
SHOW server_version_num;

其中 server_version_num 是数值型版本号，便于脚本比对。例如 160004 表示 16.4。验收基线应明确到小版本，并约定小版本升级策略：是允许滚动升级到同主版本最新小版本，还是必须锁定到某个具体小版本。若使用编译安装，还要记录 configure 选项，尤其是是否启用 --with-openssl、--with-libxml、--with-uuid 等，这些直接影响扩展可用性。

扩展核查

扩展是验收中最容易“环境有、生产无”的差异点。核查命令为：

SELECT extname, extversion, extnamespace::regnamespace
FROM pg_extension
ORDER BY extname;

基线表应逐行记录扩展名称、版本、安装 schema 以及是否随数据库创建自动安装。常见需要重点确认的包括 pg_stat_statements（性能观测）、pgcrypto（加密函数）、uuid-ossp 或 pgcrypto 的 gen_random_uuid、postgis（空间数据）、pg_partman（分区管理）。若扩展依赖外部共享库，还要确认 shared_preload_libraries 中已正确加载，否则部分功能在重启后才会暴露缺失。

参数核查

参数核查要区分“必须一致”和“允许按环境调整”两类。必须一致的通常包括 wal_level、max_wal_senders、max_replication_slots、archive_mode、shared_preload_libraries、password_encryption、ssl 等，它们决定复制、备份和安全的可行性。允许按环境调整的包括 shared_buffers、work_mem、maintenance_work_mem、max_connections、effective_cache_size 等，但调整必须有依据并记录在案。

建议用一条查询导出关键参数快照：

SELECT name, setting, unit, source
FROM pg_settings
WHERE name IN ('wal_level','max_wal_senders','max_replication_slots',
               'archive_mode','shared_preload_libraries','password_encryption',
               'ssl','shared_buffers','work_mem','max_connections',
               'timezone','log_timezone','client_encoding','server_encoding')
ORDER BY name;

其中 source 列非常关键，它告诉验收人员该值来自默认、配置文件、命令行还是会话级设置。若关键参数来源是 default 而非 configuration file，说明配置文件可能未生效，需要重点排查。

字符集、时区、网络与存储

字符集核查要同时看服务端编码、排序规则和字符分类：

SHOW server_encoding;
SHOW lc_collate;
SHOW lc_ctype;
SELECT datname, pg_encoding_to_char(encoding), datcollate, datctype
FROM pg_database;

生产环境通常要求 UTF8 编码，排序规则需与业务语言一致。若使用 ICU 排序规则，还要记录 ICU 版本，因为不同 ICU 版本对同一字符串的排序结果可能不同。

时区核查要区分数据库时区、日志时区和操作系统时区。数据库时区影响 timestamptz 的显示，日志时区影响排障时的时间对齐。核查命令为 SHOW timezone;、SHOW log_timezone; 以及 timedatectl。三者不一致时，必须在基线中写明差异原因，否则跨系统日志关联会非常困难。

网络核查包括监听地址、端口、连接串和防火墙策略。执行 SHOW listen_addresses;、SHOW port;，并确认 pg_hba.conf 中允许的客户端网段与验收范围一致。存储核查则要确认数据目录路径、文件系统类型、挂载参数和可用容量：

SHOW data_directory;
df -hT $(psql -Atc "SHOW data_directory")
mount | grep $(psql -Atc "SHOW data_directory" | cut -d/ -f1-3)

需要特别关注 noatime、data=ordered 等挂载选项，以及是否使用 LVM、是否启用透明大页。透明大页在部分负载下会引起延迟抖动，验收时应记录其状态并给出是否关闭的结论。

验收核对表示例

下表是一份可直接填写的核对表模板，字段按“核查项—实际值—期望值—判定—备注”组织，覆盖本节八个维度。实际使用时，每个项目应指定采集人和复核人。

最后强调一点：基线核查的产物不是一张一次性表格，而是一份可重复执行的脚本或检查清单。建议把上述查询封装成 baseline_check.sql，每次环境变更后重新执行并归档输出，这样验收交付时拿出的不是口头承诺，而是可追溯、可复现的环境证据链。