附录 A：版本矩阵与差异注记

本附录是全书的版本控制面。正文中的原理尽量保持跨小版本稳定，但命令、默认值、组件组合和界面必须绑定实际版本。读者复现实验时，先记录事实，再判断差异是否影响结论。

A.1 PostgreSQL、Pigsty、OS、Patroni、PgBouncer、备份工具与扩展版本

当前写作基线：

L2 的三台 pg-test VM 在正式 run 中只有 1 vCPU、约 1.9 GiB RAM，是明确记录的 sandbox exception；它证明实验在该下限跑通，不构成生产 sizing。精确资源、网络和 限制见附录 E与 ch19/requirements.json。

Patroni、PgBouncer、HAProxy、pgBackRest 与扩展的小版本可能随操作系统仓库和离线包变化，因此不在正文中假定一个虚假的全平台统一值。进入实验节点后采样：

{
  printf 'captured_at=%s\n' "$(date -Is)"
  uname -a
  cat /etc/os-release
  postgres --version
  psql --version
  patronictl version
  pgbouncer --version
  haproxy -v
  pgbackrest version
} > component-versions.txt 2>&1

命令不存在或需要不同 PATH 时，保留失败输出并从软件包管理器补充，不得把“未采集”写成“未安装”。服务端 PostgreSQL 版本还要从连接内部复核：

SELECT
    current_setting('server_version') AS server_version,
    current_setting('server_version_num') AS server_version_num,
    version() AS build;

扩展分为“操作系统已提供”和“当前数据库已安装”两层。后者使用：

SELECT extname, extversion
FROM pg_catalog.pg_extension
ORDER BY extname;

不要用 pg_available_extensions 代替已安装清单，也不要假设一个数据库安装的扩展会自动出现在同实例的其他数据库中。

A.2 强版本相关行为：并发 DDL、预备语句、排序规则、升级与恢复

下列主题不得只写“PostgreSQL 支持”：

强版本相关实验在正文中同时给出“本书基线的已验证路径”和“迁移到其他版本时要重新验证的观察点”。不能验证的行为明确标为未决，不用相近版本输出冒充。

A.3 版本增量通过记录与勘误链接

每次升级写作基线都执行一次版本增量通过：

1. 创建全新的 L1，记录安装制品校验值与全部版本；
2. 从 ch01 开始运行 setup、exercise、verify 与 reset；
3. 对比系统目录、命令输出、默认值和服务路由；
4. 将差异分为“输出变化”“行为变化”“安全边界变化”“实验失效”；
5. 修正文稿与脚本，并记录最小受影响版本范围；
6. 三种样章通过后，再推进全书回归。

勘误记录至少包含：

版本更新不覆盖历史事实。若旧版行为在当时确实成立，应保留适用范围并补充新行为；只有事实本身错误时才作为勘误修正。