由 John Doe 四月 27, 2026
Postgres 的开发流程既有其他开源项目的典型特点，又因构建高可靠数据库系统的复杂需求而独具特色。本文介绍 Postgres 开发模式，并说明采用这些流程的原因。
目录
自 1996 年以来，PostgreSQL 由一支不断壮大的志愿者团队开发。团队汇聚了全球顶尖的数据库开发者，他们通过互联网协同工作，打造出全球最先进的开源数据库。
社区开发模式难以被理解，因为它没有传统开发团队的常规架构：没有单一权威、没有缺陷跟踪系统、没有开发路线图、没有发布目标日期。部分机制缺失源于项目的开源属性，另一些则是因为非正式结构被证实对本项目更高效、更务实。
没有单一权威
Postgres 开发者之间不存在单一权威。所有讨论都在开发者邮件列表进行，任何人都可以发表意见。这让更多人能参与复杂决策，有两大优势：
- 鼓励相关领域专家贡献见解
- 无参与门槛，让新人感受到自己是项目的一部分
很多复杂决策往往会受到非核心贡献者的影响，因为他们拥有资深开发者所欠缺的视角与经验。
没有缺陷跟踪系统
Postgres 不使用缺陷跟踪系统。传统缺陷跟踪系统是开发生态的一部分：用户提交报告、管理员筛选无效问题、指派开发者处理。最糟糕的情况是，缺陷系统沦为只记录不解决的 “垃圾场”。
Postgres 通过邮件列表收集缺陷报告，把缺陷管理工作分散给所有邮件订阅者。由于只有少量报告是真实缺陷，订阅者可与提交者沟通确认现象。有效缺陷通常能被资深开发者快速识别，要么立即修复，要么加入待办清单。
没有开发路线图
作为无资产的社区项目，无法可靠地统筹开发方向。开发团队虽可引导大家聚焦特定功能，但功能开发高度依赖贡献者的自愿时间与企业赞助。没有路线图能让项目随社区需求变化持续调整方向。
开发主要通过黑客邮件列表沟通，日均约 85 条消息，涉及功能讨论、补丁评审、缺陷修复。主代码库使用 Git 管理，约 15 名活跃人员负责处理社区提交的补丁。
没有发布目标日期
数据库必须可靠，否则毫无价值。核心开发者虽计划每 12–14 个月发布一个大版本，但代码可靠性决定发布时间。
开发流程
典型的开发周包含：约 10 位长期贡献者讨论核心功能、多位首次贡献者提交补丁待审、数十份缺陷报告需要排查，修复或加入待办清单。
每两个月举办一次 CommitFest，集中处理所有已提交但未合入的补丁，通常持续一个月。约九个月后，CommitFest 暂停，汇总所有遗留问题并处理，随后发布首个正式测试版（Beta）。一般会推出多个 Beta 版，直到代码足够稳定，再发布候选版（RC）。若候选版实测反馈良好，就发布最终正式版，几周后新一轮开发周期启动。
支撑工具
对于复杂的数据库源码，回归测试不足以发现大部分缺陷。补丁评审才是确保新增代码修复问题、而非引入新缺陷的主要手段。
多款工具保障代码规范与稳定：
- Postgres Buildfarm：标出需要修复的不可移植代码结构
- 开发工具：统一代码缩进格式
- 丰富文档：帮助新人上手，开发者 FAQ 是最佳起点
新开发者
Postgres 对 SQL 标准兼容性、代码整洁度、可靠性要求严苛，常让新人感到受挫。1996 年，开发者从加州大学伯克利分校继承了已有十年历史的成熟代码库，从一开始就强化了长期维护的高标准。与多数开发组织不同，Postgres 开发者不只关注短期，更看重当下的工作如何影响数据库未来多年的运行。
结论
Postgres 的部分流程与其他开源项目相同，另一些则因可靠性要求、长期维护需求和数据库软件的复杂性而独一无二。尽管这套模式让新人感到意外，但它运行良好，并得到了历经 30 年发展沉淀的社区广泛认可。