本文整理于 HOW 2026 演讲内容，演讲者：厉超，瀚高数据库首席架构师。

前言

PostgreSQL作为全球最先进的开源关系型数据库之一，其成功不仅源于卓越的代码质量，更得益于一个健康、开放、持续。

截至2026年，PostgreSQL社区已有31位Committer、7位Core Team成员，以及遍布全球的数千名活跃贡献者。然而，中国在PostgreSQL国际社区中的力量仍相对薄弱——目前仅有郭峰（Richard Guo）一位来自中国的Committer。这既是一个现实，也是一个机会。

本文作者厉超，现任瀚高数据库PG社区开发工程师，在加入瀚高之前，曾先后在朗讯（15年）和VMware（12年）从事研发工作，是一位拥有近三十年编程经验的资深开发者。2025年7月，他正式加入瀚高，投身PostgreSQL社区贡献。本文基于他在HOW 2026开源生态大会暨PostgreSQL高峰论坛上的演讲内容整理，系统梳理了PG社区的治理机制、参与贡献的实操路径，以及近一年来积累的经验与教训，希望为有志于参与PG社区的中国开发者提供一份实用的参考指南。

一、PostgreSQL社区的治理机制

1.1 社区运行模式

PostgreSQL社区有其独特的运行方式，与传统商业软件公司有着本质区别。

对所有人开放：无论你是社区大佬还是新人小白，社区都欢迎你的加入。只要你能够用英文进行沟通，就可以参与其中。

无专职人员：PG社区没有任何一个人是由PostgreSQL“发工资”来为其工作的。所有人都服务于各自的公司，利用业余时间或公司允许的工作时间为社区做贡献，本质上所有人都是“兼职”的。

无传统组织架构：社区没有类似传统公司的组织架构，也没有例行的管理会议。有人曾以为Core Team成员会定期开会讨论社区重大方向，但实际情况并非如此——PG每年在全球有60多场大会，这些会议才是核心成员和贡献者们相见、交流的时机。

民主集中制：这是社区运作的核心原则。“民主”体现在，无论大佬还是新人，所有人的意见都会被尊重。提交一个patch后，任何人都可以参与review，只要提出的意见有价值，就一定会得到重视。如果patch作者没有解决这些有价值的意见，patch就不可能被推进。“集中”则体现在最终决策上——在代码层面，通常由Committer做最终裁决；在更大的技术路线选择上，则由Core Team把控方向。

实用主义优先：PG的代码质量虽然非常高，但并非绝对意义上的完美。由于所有参与者都不是全职投入，31位Committer的精力有限，因此社区更强调实用主义，而非形式上的完美。如果一个改动影响到用户使用体验——它是一个bug——那一定会被修复；但如果只是代码层面的小瑕疵，未必会被接受。

最宽松的License政策：PG拥有全世界最宽松的开源许可证之一，这吸引了无数公司基于PG提供商业服务，而这些公司又会通过允许员工为PG工作、提供赞助等形式反哺社区，形成良性循环。

电子邮件为核心沟通工具：PG社区最主要的沟通方式是电子邮件（Email）。所有讨论、代码审查、决策过程都通过邮件列表进行。

1.2 代码贡献流程

向PG贡献代码的标准流程如下：

1. 产生想法：确定要修复的bug或要新增的功能
2. 编写代码：完成代码开发并充分测试
3. 生成patch文件：准备好所有改动
4. 提交到社区：通过电子邮件将patch发送到pgsql-hackers邮件组
5. 代码审查：社区成员（通常是对该领域感兴趣的人）通过回复邮件的方式提出review意见
6. 迭代修改：根据意见修改后，将新版本patch再次通过邮件发回社区
7. 合并代码：如果patch被某位Committer注意到并认可，就会被合并到PG主分支

1.3 社区角色与认证层级

PostgreSQL社区建立了清晰的贡献者认证体系，从低到高依次为：

Hacker（贡献者） ：所有参与到PG代码贡献的人统称为Hacker。无论是Tom Lane这样的大佬，还是刚加入社区只做过一次review的新人，大家都是Hacker。

Significant Contributor（重要贡献者） ：指近年来持续作出多项重要贡献的个人。根据社区惯例，获得这一称号通常需要持续贡献三到四年（当然，如果贡献特别突出，两年左右也有可能）。这一称号是由PG官方正式认证的。

Major Contributor（主要贡献者） ：指多年来持续贡献，并对PostgreSQL社区发展产生重大积极影响的个人。这种“积极影响”未必完全是代码层面的，也可能是组织活动、文档贡献等其他方面。

Committer（提交者） ：有权限向PG代码库提交代码的人。目前全世界共有31位Committer，其中中国只有一位——郭峰（Richard Guo）。成为Committer的条件包括：

• 数年的大量项目贡献
• 多项持续性的代码贡献
• 负责代码库一个或多个领域的维护工作
• 有review和帮助其他贡献者处理patch的记录
• 代码贡献质量高，提交前几乎不需要修改
• 充分理解patch接受的流程和标准

Committer采用提名选举制——由现任Committer提名并投票，一般每年进行一次。

Core Team（核心团队） ：目前共7人，是PG社区的最终决策机构。其职责包括：

• 协调发布活动
• 作为保密沟通的渠道
• 制定政策声明
• 管理权限（commit、基础设施等）
• 处理纪律问题
• 在缺乏共识时做艰难决策

Core Team通常不介入适合公开讨论的事务（如技术方向和宣传推广）。新成员由现有Core Team成员任命。

二、如何参与社区贡献

2.1 邮件工具的选择与配置

由于Email是PG社区的基本沟通工具，选择合适的工具和正确使用方式至关重要。

邮箱选择：个人建议使用Gmail。开始参与社区贡献时，作者曾试用多个邮箱，最终发现Gmail对PG社区最为友好。国内常用的163、126等邮箱的网页版对PG社区的邮件格式支持较差，容易出现格式混乱。

邮件客户端：

• 苹果系统：自带Mail即可
• 其他系统：推荐Thunderbird（社区中使用非常广泛）

邮件格式：

• 最好使用纯文本（plain-text）格式，不要使用富文本（rich text）。PG所有邮件都会被归档到Mail Archive系统中，该系统对富文本格式支持不佳。
• 回复邮件时，将回复内容写在引用段落下方（即“按引用逐段回复”），避免top-posting（在邮件顶部直接回复）。这一点与大部分邮件客户端的默认行为相反，需要特别留意。
• PG社区邮件常以“Hi,”开头，不带具体人名——这并非不礼貌，而是社区习惯，相当于“Hi all”。

2.2 社区账号注册

• 访问 https://www.postgresql.org/account 注册账号
• 设置主用邮箱和备用邮箱
• 注册后可先认识社区中的关键人物：
  • Core Team名单：https://www.postgresql.org/community/contributors/
  • Committer名单：https://www.postgresql.org/developer/committers/

2.3 邮件列表订阅

访问 https://lists.postgresql.org/manage/ 订阅相关邮件列表。常用列表包括：

• pgsql-hackers：代码相关（日常使用最多）
• pgsql-bugs：报告bug
• pgsql-translators：翻译相关问题
• pgsql-general：普通问题咨询

特别提醒： 不要发送测试邮件。不确定邮件客户端配置是否正确时，不要在社区邮件列表中发测试邮件，否则很快会有人提醒你。

2.4 Message ID——邮件追踪的钥匙

每一封电子邮件都有一个Message ID，可以从邮件客户端的“查看源代码”（Raw Source）中找到邮件头中的这个字段。

在PG社区中，Message ID非常重要——每一个patch的ID就是其起始邮件的Message ID。将patch提交到CommitFest系统或其他平台时，就是通过Message ID来标识的。

通过以下URL格式可以随时打开PG历史上任何一封邮件：

https://www.postgresql.org/message-id/[MessageID]

2.5 CommitFest系统

由于所有patch都通过邮件提交，邮件数量庞大容易沉没，PG提供了 CommitFest系统（https://commitfest.postgresql.org/）来追踪patch状态。

注册注意事项：注册后有“冷静期”（Cool Off Period），约一周内无法登录，因此建议提前注册。

CommitFest的作用：

• 追踪patch的当前状态
• 自动提供CI测试（在所有系统上运行完整测试）
• 便于其他贡献者找到你的patch进行review
• reviewer审核通过后可将patch标记为“Ready for Committer”，方便Committer注意到

需要强调： CommitFest只起追踪作用，所有讨论仍通过邮件进行。

三、经验与教训

3.1 经验篇

（1）有耐心，不急于回复

这与在企业中工作有很大不同。在公司里，及时性往往比准确性更重要——收到邮件可能五分钟内就回复，即使有小瑕疵也可以通过后续沟通澄清。

但在社区中，邮件回复的节奏完全不同——贡献者分布在世界各地，且都不是全职投入，邮件滞后性很强。因此，无论是写邮件还是回邮件，不需要着急那一小时两小时，甚至不需要着急一两天。 确保每一封邮件都写得准确、高质量、意思表达清楚，比追求速度重要得多。

（2）多做review——以小积大

PostgreSQL是一个非常庞大、复杂的系统，系统性地学习非常困难，而且常常学了这块就忘了那块。通过review patch，可以带着任务去学习特定模块的知识。

对作者个人而言，每次review一个patch，就在自己对PG的认知拼图上多拼一小块。久而久之，PG的全貌逐渐在大脑中完整起来。 通过review学到的知识，远比空泛地阅读文档要深入和持久。

此外，通过做review、测试相关代码，还能发现很多自己可以写patch的机会——这是一个良性循环。

（3）谨慎对待memory leak问题

PG有一套自己的内存管理机制——内存上下文（Memory Context）。在这种机制下，并非每一个分配的内存都需要显式释放，最终都会被Memory Context统一回收。

因此在代码中能看到一些不一致的情况：某个函数分配了内存并释放，另一个相似函数分配了内存却没有释放——这未必是bug，可能两种写法都可以。 如果你提交一个patch去“修复”这种问题，有可能被接受，也有可能不被接受，取决于Committer当时的精力状态。当Committer比较忙时，对这种“小瑕疵”类的问题往往比较反感。所以需要谨慎对待所谓的“memory leak”。

（4）不要随便主张性能提升

学习C语言时我们都知道，右移操作比乘法快——但现代编译器可以自动完成这类转换。所以把代码中的 *2改成 <<1并不会带来实际性能提升。

如果确实做了算法层面的改进， 一定要用数据说话。Tom Lane曾在邮件中明确表示：如果改动能够带来 5%以上的性能提升，可以主张这是性能优化，但必须附上benchmark数据作为支撑。如果没有数据，只是一个1%-2%的猜测性提升，就不值得专门拿出来说。

（5）多关注近期合并的commit，抓住时机

有些patch可能提交几个月甚至半年都无人问津，但近期如果有类似的改动被合并，就是一个重新激活旧patch的好机会——可以借此重新审视、更新自己的patch，引起社区注意。

（6）提交时机的把握

分析PG近三年（2023年4月至2026年3月）每月commit数量的趋势可以发现：

• 总体趋势向上：以年为单位，每年的commit数量都在增长，说明PG社区持续活跃、健康发展
• 年度周期规律：
  • 每年3月：commit数量达到高峰
  • 4月开始下降
  • 5-6月达到最低谷
  • 7月开始回升

这一规律的原因是：每年4月是下一个版本的 Feature Freeze（功能冻结）日期——此后不再接受新功能，只处理已发现bug的修复。5-6月处于新版本的测试阶段，commit数量自然减少。7月新版本分支创建后，新功能重新被接受，commit数量开始回升。

对新人而言，提交时机的选择很重要。如果在5月提交一个新功能，大概率要等三个月才有人回复；但如果7月提交，可能第二天就有人回应。所以，如果发了patch没有人回，不要灰心，可能只是时机问题。

3.2 教训篇

（1）不要图快，确保质量

作者在社区中也曾被“怼”过很多次，最主要的原因就是刚开始时只图快——别人回复了什么，尽快回复出去。回复太快，难免犯错；而在一封邮件被无数人关注的环境下，任何小错都可能被放大。

在PG社区回复邮件时不图快，确保每一行代码、每一封邮件都保持尽可能高的质量，尽量避免低级错误。你的想法跟别人不一样完全没问题，但不要犯那些可以避免的低级错误。

（2）不要盲目发小patch

不要盲目地发一些“修复memory leak”或“主张无谓性能提升”的小patch。这类patch确实可以找到很多，但发多了对个人在社区的声誉和成长没有任何帮助，反而可能让人觉得你在“刷存在感”。

（3）发patch之前一定要build和测试

这是一个基本要求—— 确保代码能够编译通过，测试全部通过，然后再发到社区。把一个没有经过基本验证的patch发到社区，是对reviewer时间的不尊重，也会损害个人在社区中的信誉。

四、关于AI的使用

4.1 必须肯定AI的帮助

在当今时代，没有人可以否认AI的价值。包括PG社区贡献在内，AI的帮助是非常大的。

AI可以帮忙做什么：

• 理解背景知识
• 润色邮件（对非英语母语者尤为有用）
• 辅助review patch
• 辅助生成代码

4.2 使用AI的注意事项

邮件内容必须自己负责：AI可以帮助润色文字，但邮件的 内核和思想必须是你自己的。AI写出来的文字可以接受，但邮件表达的观点、提出的技术方案，必须由你自己负责。

AI review的结果需要人工确认：AI可以帮助review patch，但根据作者的个人经验，AI review出来的意见80%以上是错误的或不可接受的——尽管如此，它依然有帮助，可以提供一个初步的参考。但AI给出的所有意见，都还需要人工去逐一确认和判断。

AI生成的代码不能直接提交：尤其是最近几个月，作者在使用Codex等工具时，能够明显感受到AI生成代码的质量在不断进步。但在PostgreSQL这样一个复杂系统中，AI给出的方案往往 不是最优解。因此：

• AI生成代码后，自己必须 完全看懂每一行
• 必须人工调整和优化，找到最优方案
• 社区才可能接受

社区对AI代码持谨慎态度：就目前而言，除非是只有一两行的超小改动，稍微大一点的改动，AI还是无法完全生成能够直接提交的PG代码。PG社区对AI直接生成、未经充分人工消化的代码持比较谨慎的态度。即使用了AI做辅助，所有内容个人必须完全理解，在这个理解的基础上调整到最优状态再提交。

4.3 个人态度

“AI帮我干活，但AI代替不了我的思想。”

结语：PG社区需要更多中国力量

从社区数据来看，PostgreSQL正处在一个持续健康发展的轨道上——每年commit数量稳步增长，全球贡献者日益增多。然而，中国在PG国际社区中的代表性仍然不足：31位Committer中只有1位来自中国。

这不是能力问题，更多是参与度和持续性的问题。PG社区的认证体系——从Hacker到Significant Contributor，再到Major Contributor、Committer，乃至Core Team——提供了一条清晰的成长路径。只要持续投入、注重质量、耐心积累，每一位中国开发者都有机会在这条路径上走得更远。

瀚高数据库始终将PG开源社区视为立身之本，大力鼓励内部员工参与社区贡献，营造了浓厚的开源氛围。这种来自企业的支持，是个人参与社区贡献的重要后盾。

以开源之道，见致远之志。期待更多中国开发者加入PG Hacker的行列。

延伸资源导航