Elizabeth Garrett Christensen：Postgres 架构三十年：Tom Lane 访谈
内容提要
PostgreSQL 迎来30周年，核心开发者Tom Lane回顾项目历程。他指出进程隔离模型带来代码简洁与崩溃恢复优势，但连接扩展需依赖连接池。MVCC和WAL设计成功，将维护工作推给后台。项目坚持可扩展性，但解析器仍难扩展。治理靠邮件共识，无正式路线图。AI生成报告增多，社区强调人类需对代码负责。
延伸解读
进程隔离模型的取舍
Postgres 为每个连接创建独立进程，带来代码简洁和崩溃恢复优势，但连接扩展需依赖连接池。Tom Lane 指出，若单个进程崩溃，postmaster 仍会终止所有子进程并重建共享内存，因此崩溃隔离的实际收益有限。转向线程模型可减少上下文切换开销，但需解决跨会话共享目录缓存等难题，目前尚无明确时间表。
MVCC 与 WAL 的设计智慧
Postgres 采用 MVCC 和 WAL，将维护工作推给后台进程。更新行时写入新版本，旧版本由 VACUUM 清理；WAL 确保提交前只需写入日志流，崩溃后可重放。Tom Lane 认为这避免了 undo 系统在事务回滚时的额外开销，并将 checkpoint 等 I/O 操作异步化，使事务提交无需等待数据页落盘。
扩展性的边界与解析器难题
Postgres 以可扩展性为核心，支持自定义数据类型、索引和过程语言，但 SQL 解析器仍难以扩展。Tom Lane 解释，解析器由 Flex 和 Bison 生成静态语法表，无法动态修改。尽管可扩展解析器在理论上可行，但 Bison 能保证语法无歧义，而替代工具难以提供同等正确性保证，因此解析器扩展仍是短板。
治理模式与项目稳定性
Postgres 没有正式路线图或法律实体，依赖邮件共识和核心团队的非正式影响力。Tom Lane 坦言，这种模式源于早期无法强制他人，但意外带来了稳定性：大补丁需多年审查，项目不会因单一公司或个人的兴趣而快速转向。数据库用户偏好“无聊”的技术，这种缓慢演进反而符合需求。
Q&A
Postgres 为什么采用每个连接一个独立进程的模型，而不是线程模型？
Tom Lane 表示，进程隔离模型主要带来代码简洁性：编写直线代码时无需担心其他线程中途修改数据结构。同时也有崩溃恢复优势：单个会话进程崩溃不会破坏 postmaster 状态，系统可安全重启。但缺点是连接扩展需要依赖连接池。
Postgres 的 MVCC 设计有什么优点？
MVCC 将维护工作（如清理死行）推给后台 VACUUM 进程，不干扰用户实际工作。相比基于 undo 日志的系统，无需在事务中止时回放 undo，也能提供一致性快照而不阻塞。Tom Lane 认为这是根本上的好设计。
Postgres 的 WAL 机制如何工作，为什么能提高可靠性？
WAL 在修改共享缓冲区前先记录变更到日志，提交时只需确保 WAL 落盘，无需等待所有数据页写回。崩溃后可通过重放 WAL 恢复。这减少了提交前的磁盘写入，并使崩溃恢复成为可能，是 Postgres 成为生产级数据库的关键。
Postgres 的查询规划器面临哪些主要挑战？
规划器需从多种执行策略中按成本模型选择最优计划，但成本模型不一定符合现实；且连接表数量增加时，可能计划数指数增长，只能启发式搜索部分计划空间，可能找不到好计划。改进成本模型与减少规划时间存在冲突。
Postgres 的扩展性如何？哪些部分难以扩展？
Postgres 从 Berkeley 时代就支持扩展新数据类型、索引访问方法等，但 SQL 解析器无法扩展，因为使用 Flex 和 Bison 静态生成解析表。添加新关键字或子句需要修改核心代码，而核心补丁审查周期可能长达数年。
Postgres 的治理模式是怎样的？为什么没有正式路线图？
Postgres 治理基于邮件共识，没有正式法律实体或路线图。核心团队无正式权力，决策靠说服。这种模式源于早期条件：代码来自 Berkeley，贡献者互不隶属，强治理会导致人员流失。项目变化缓慢，但带来稳定性。
