PostgreSQL 主版本之间的升级非常烦人。您不能只安装服务器二进制文件然后重新启动，因为数据目录的格式不兼容。

为什么会这样？为什么我们不能保持数据格式兼容呢？

令人惊讶的是，数据格式实际上大部分兼容，但并不完全兼容。出现一些很难解决的问题。

让我们看看可能的升级程序：

1. pg_upgrade
2. 使用 pg_dumpall 转储和恢复
3. 逻辑复制到新实例

2 和 3 本质上是相同的想法：构建一个新的实例，并以更高级别的兼容格式在实例之间传输数据。

pg_upgrade更有趣。pg_upgrade 所做的是：

1. 使用 pg_dump 转储旧数据库的架构，并将其还原到新数据库。（实际上，针对实例中的每个数据库分别进行，并与 pg_dumpall结合使用，但这在这里并不重要。）
2. 将数据文件直接从旧实例复制到新实例。

因此，包含表和索引数据的数据文件在主要版本之间实际上是兼容的。自从引入pg_upgrade 以来，它们已经兼容了很长时间。

如何管理取决于这些文件中的内容。例如，btree 有一个简单的版本控制机制：

#define BTREE_VERSION   4       /* current version number */
#define BTREE_MIN_VERSION   2   /* minimum supported version */
复制

堆更复杂，它只需保持与旧版本可能存储的内容的兼容性。但这都是可行的。

不兼容的是模式（数据定义、表的元数据等）的存储方式。这就是 pg_upgrade 所存在且需要解决的问题。

那么为什么主版本之间的架构存储不兼容呢？

PostgreSQL 数据库的架构数据存储在所谓的 系统目录中，这些目录本身就是表。出于引导原因以及一些效率原因，这些系统目录的结构在服务器中是硬编码的。例如，当系统想知道列的名称时，它会加载行pg_attribute，并且它知道具有列名的字段从什么偏移量attname开始。这必须是硬编码的，因为，您无法查询pg_attribute以查找有关的信息pg_attribute。

每当实现需要在系统目录中存储某些信息的新功能时，这些硬编码的知识就会变得不正确。例如，在 PostgreSQL 17 中，订阅获得了一个新的 故障转移标志。此故障转移标志需要存储在某个地方。它存储在 目录subfailover的字段 中pg_subscription 。因此，pg_subscription 行的硬编码大小会发生变化，新字段后某些字段的偏移量 subfailover也会发生变化。

对此看似有一个显而易见的解决方案：服务器源代码只需包含旧目录布局的条件代码即可。但这种代码非常普遍，粗略估计显示有超过一千个实例。因此，实现这一点将是一项巨大的努力，并且需要大量的持续维护。所以在实现这一点之前，需要一些新的想法来首先重构其中的一些内容。

另一个问题是，这仍然无法解决将系统目录升级到新布局的方法。如果您升级到 PostgreSQL 17 并想要创建故障转移订阅，这是无法做到的，因为目录仍为旧格式。然后您仍然需要以某种方式升级它们，并且您需要工具来管理所有这些。

现在，在另一个世界里，系统目录的设计会有所不同，考虑到兼容性和可升级性。系统目录是普通表的想法可能是 Berkeley Postgres 的原创想法。它确实很棒，因为它为您提供了一些有用的功能，尤其是事务性 DDL，而且只需付出相对较少的额外努力。但它确实使格式更难升级。

所以我倾向于认为这是这些历史架构决策的权衡：轻松升级或轻松事务 DDL。

需要明确的是，这并不是轻松升级的唯一障碍。但我认为这是最重要的障碍。另一个障碍是，记录系统目录中存储的视图或存储的默认表达式等内部数据结构的序列化格式未针对主要版本之间的兼容性进行管理。因为到目前为止还没有必要。但我认为可以找到解决方案。有很多这样的事情，我们甚至没有认真考虑过，因为还没有必要。例如，预写日志 (WAL) 的格式在主要版本之间不兼容。由于 pg_upgrade 和其他升级程序都不保留 WAL，所以这不是问题。我在这里提到它只是为了表明，如果解决了我们所知道的问题，还有其他较少探索的问题。

      #PG证书#PG考试#PostgreSQL培训#PostgreSQL考试#PostgreSQL认证

作者：Peter Eisentraut
原文链接：https://peter.eisentraut.org/blog/2024/11/26/why-postgresql-major-version-upgrades-are-hard