塑造 Postgres 架构的三十年：Tom Lane 访谈

这篇对 Tom Lane 的深度访谈——他作为 PostgreSQL 项目的核心开发者，迎来了担任提交者的第二十五个年头——审视了那些支撑这个开源数据库走过三十年历史的基础性架构选择。

Postgres……关于这个神奇的工具可以说的太多了，而 IProgrammer 对此了如指掌。在 IProgrammer 众多关于 Postgres 的文章中，与本次访谈最相关的当属“Postgres 的持久影响”；这篇对 Postgres 项目的历史回顾及其对 DBMS 行业的影响，深入剖析了 Mike Stonebraker 所构想的对象关系数据库的关键特性。这些特性包括：

在数据库系统中支持 ADT
商业化的改编
开源
支持多种语言模型
支持多处理器：XPRS
以日志为中心的存储与恢复
主动数据库与规则系统
面向新数据类型的可扩展访问方法

本次访谈由 Elizabeth Garrett Christensen 代表 Snowflake 进行，内容围绕支撑这一切运转的基础设施；那些支撑这个开源数据库走过三十年历史的基础性架构选择，包括其独特的每连接一进程模型、用于崩溃恢复的预写式日志（WAL）以及多版本并发控制（MVCC）。

除此之外，Tom Lane 还讨论了该项目非正式的治理结构、对 C 内存上下文进行资源管理的广泛依赖，以及在维护稳定核心与支持多样化扩展之间持续保持的平衡。让我们逐一来看。

1. 每连接一进程模型
与 MySQL 或 SQL Server 等使用线程的数据库不同，Postgres 会为每个客户端连接生成一个独立的操作系统进程。这样做的好处是代码简单和崩溃隔离。开发者可以编写直线式代码，无需担心并发线程破坏私有内存结构。如果某个会话崩溃，postmaster 进程会终止所有子进程并安全地重新初始化共享内存。在 20 世纪 90 年代，避开未标准化的线程实现让 Postgres 保持了简单性，使新贡献者能够轻松地修改代码库。

但这也存在权衡。每个进程都携带沉重的目录缓存和私有内存映射。高连接数会增加 CPU 上下文切换开销，这促使生态系统依赖 PgBouncer 之类的连接池工具。

2. 预写式日志（WAL）与恢复
当 Postgres 由加州大学伯克利分校发布时，它完全没有预写式日志；崩溃往往意味着要从备份中恢复。引入 WAL（最终在 Postgres 8.0 中完成）将 Postgres 从一个学术项目转变为生产级数据库。

在其机制下，更改会在更新共享缓冲区页面之前，按顺序写入单一的 WAL 流。事务一旦 WAL 落盘即提交，将随机页面同步推迟到后台检查点。为保证可靠性，崩溃恢复重放被有意保持为简单的单进程操作。

3. 多版本并发控制（MVCC）
Postgres 不会覆盖行，也不依赖 undo 日志来处理并发读写，而是追加一份新的行副本，并在头部写入事务元数据。其架构优势在于：读操作永远不会阻塞写操作，写操作也永远不会阻塞读操作。通过 VACUUM 和 autovacuum 清理死元组版本的维护工作被推入后台进程，而不是阻塞事务的中止或提交。

4. 内存上下文层级
Postgres 不使用标准的 C malloc/free 例程或语言强制的所有权模型，而是使用一棵与特定生命周期（会话、查询或行级别）绑定的命名内存上下文树。其影响是：当查询或事务结束时，其整个内存上下文树会一次性释放。这消除了零散的 free() 调用并防止内存泄漏，使 C 内存管理在 150 万行代码中保持稳健。

5. 将可扩展性作为核心约束
可扩展性从 Postgres 的伯克利根源起就被融入其中（自定义类型和索引访问方法）。如果提议的核心功能无法扩展以支持自定义扩展类型，社区就会拒绝它，直到它被泛化。这一理念使得扩展成为可能，而不会使核心引擎臃肿或分裂社区。用 Flex 和 Bison 构建的核心解析器有意保持静态，以维护语法正确性保证。

在“ElasticSearch Search Capabilities Baked Into PostgreSQL”一文中，我们记录了该能力：

pg_ivm - Materialised Views On Steroids
一个用于 PostgreSQL 14 的扩展模块，提供增量视图维护（IVM）功能。这意味着物化视图会在基表被修改后立即更新。

pgsqlite - Load SQLite databases into PostgresSQL
一个纯 Python 模块和命令行工具，可轻松将 SQLite 数据库导入 Postgres，在此过程中节省大量时间和麻烦。

pg_later - Native Asynchronous Queries Within Postgres
由 Tembo 构建的一个有趣项目和扩展，使 Postgres 能够异步执行查询。发出你的查询——但别忘了稍后检查结果。

Hydra Turns PostgreSQL Into A Column Store
Hydra 是一个开源扩展，为 Postgres 添加列式表，以实现高效的分析报告。

Turn PostgreSQL Into A Vector Store
pg_vector 是 PostgreSQL 的一个扩展，使其成为 LLM 中使用的专用向量存储的可行替代方案。

6. 宽松的许可与非正式治理
宽松的 BSD/MIT 风格许可证允许商业供应商和云提供商构建专有分支，同时与社区代码库保持联系。

就治理而言，该项目在没有正式法律实体或公司指导委员会的情况下运作。所有变更都通过电子邮件讨论和共识进行，从而产生深思熟虑、高度稳定的版本，其中数据库可靠性优先。

但这一切都已完成；成为书写的历史。问题是未来会怎样？项目将走向何方？

在采访中，Tom再次强调了一个观点：Postgres没有正式的项目路线图或指导委员会。由于开发是去中心化的，项目推进得很审慎，优先考虑稳定性和数据可靠性，而不是快速发布或追逐潮流。不过，有几个重大的架构转变、即将推出的功能和社区政策正在积极开发或讨论中：

架构与性能转变
转向线程模型：开发者正在积极研究将Postgres从每连接一个进程的模型转换为线程模型，以减少在高核心硬件上的CPU上下文切换开销。为了实现这一点，工程师必须解决在线程/会话之间共享目录缓存而不冒数据损坏风险的问题。

列式组织表：对于在传统的行式表之外支持列式存储，一直有强烈的兴趣。这样做需要扩展现有的表访问方法（TAM）API，以便扩展或核心功能可以支持面向列的表格式。

并行崩溃恢复：虽然在崩溃恢复期间，预写日志（WAL）重放被有意保持为单进程，以实现最大程度的简单性和安全性，但未来最终可能会并行化。

可扩展的SQL解析器：由于解析器依赖于静态的Flex和Bison表，扩展目前无法添加新的SQL语法。Tom指出，如果有一个竞争工具能够匹配Bison的正确性和歧义保证，项目将愿意使解析器可扩展。

Vacuum改进：关于autovacuum启发式和并行化维护（例如Postgres 19中的并行vacuum）的工程工作仍在继续。

核心与扩展的理念
Tom倾向于保持核心Postgres轻量精简。如果新功能或能力可以作为扩展很好地工作，他的立场是将其保持在核心引擎之外，以免核心开发者资源过于分散。

社区关于AI的政策
社区正在制定关于AI辅助代码的官方政策。目前的共识是，人类提交者必须为每个补丁背书，并能够解释每一个设计决策。

项目还经历了AI生成的错误和安全报告的急剧涌入。虽然有些是合理的，但许多缺乏架构理解，因此社区正在努力建立更好的过滤机制。

最后，就Tom的未来而言，他计划只要自己仍然投入且相关，就继续在Postgres上工作，并指出他满足于在可预见的未来继续从事核心开发。

总结一下，我必须说这次采访非常有见地，对于任何使用Postgres的人来说都是必看的。

塑造 Postgres 架构的三十年：Tom Lane 访谈

更多信息

相关文章

评论