十大顶尖高手之一吐槽：投身贡献PG的过程相当艰难！

原文作者：Robert Haas
原文标题：Hacking on PostgreSQL is Really Hard
原文链接：https://rhaas.blogspot.com/2024/05/hacking-on-postgresql-is-really-hard.html

为PostgreSQL进行编码并不是一件简单的事。很多人应该会同意作者的这个说法，尽管每个人可能有各自不同的缘由。有人可能会惊呆于邮件列表上长篇的话术讨论，也有人指出patch包审查人员短缺，还有人觉得意见难以引起提交人的重视，或者觉得提交人的想法过于脑洞。但本文作者将重点放在纯技术的角度：编写正确合理且不出bug的patch程序极端困难。

作者可以用非常多的例子来证明这个观点，但借鉴他人的示例尤显不公平，所以作者将从自身最近的经历进行举例：提交增量备份的特性。作者认为这个特性的复杂度是适中的。对于开发增量备份特性的工程，作者一开始雄心勃勃，项目参与者也是如此。这个项目实际上已经酝酿多年；其前身是PG 13的备份验证工具pg_verifybackup。时至2023年，作者再次回到主赛道，并于上半年花了几个月的时间进行增量备份的特性开发，然后当年最后一个季度又花了几个月时间，最终于2023年12月20日提交完成了这个功能。

2023年12月21日有四次修复缺陷的提交，其中两次由作者提交，另外两次由Tom Lane提交。2024年1月15日，又有超16次的后续提交，其中仅仅只有两次提交才是计划中的。这些提交里，有两次由Tom Lane提交，一次由Michael Paquier，其余的都是作者提交。在作者看来，几乎所有的提交都是在解决真正的问题。特性提交的邮件列表讨论发现了诸多疏忽，因此最初的几周，项目的开发速度确实变慢了很多，但这还不是最糟糕的情况。

2024年3月4日，作者提交了针对CREATE DATABASE指定STRATEGY场景下使用增量备份的修复程序。4月5日，作者修复了在1GB或更大尺寸上使用增量备份引起数据损坏的bug。4月19日，作者修复了用户定义表空间下无法恢复增量备份的问题。4月25日，作者再次对代码和文档进行优化：如果集群的checksum发生了更改，正常恢复进行checksum会失败。

上面的工作并未完全道尽作者为保证增量备份稳定运行所做的一切。整个项目过程中，作者多次破坏重构测试案例，大家如果有幸浏览到提交日志，应该可以看到作者为构建测试环境以及手动测试和编写自动化测试用例方面所做的疯狂努力。

有些人的提交体验可能比作者更差，可能需要花费很多时间才能提供完全修复的patch补丁包，甚至有更严重的错误直到正式发布后。作者记得有一个数据损坏案例，这个严重的bug在大约两年的时间里都没有被发现，这也并不罕见。即便最优秀的黑客程序员也很难保证不出bug。（常在河边走，哪有不湿鞋！）

假设你有幸成为一名提交人，你将不得不投入大量工作来修复bug，无论是在提交审核阶段，还是在问题发现以后，或者两者兼而有之。提交别人的补丁时，也不得不承担同样的风险，这意味着你可能不愿意做任何提交。提交其他人的补丁关键不在于git流程操作所需的时间，而是连带有审查之责。 曾经有一个patch补丁包依然令作者记忆犹新：在提交之前，作者花了数以周记的时间来审查补丁包，提交之后的六到九个月里，大部分时间作者都在对审查期间未发现的问题进行查漏补缺，在工作生涯中没有足够的月份或年份也难以经历，历经一次亦足矣！那个特定的patch给作者的体会是痛并快乐的，但对于常规的patch来说，这种痛苦并不值得。

这显然影响了想为PostgreSQL贡献提交事儿的人数。作为为一名提交者，必须让人相信你是可以被信任的人，可以为他人的补丁提供最后的兜底。这不仅需要过硬的技术，还要具备高超的外交技能。进阶为重要补丁的提交者，还必须每年持续花费数以百记的小时，甚至超过1000个小时的时间来维持必要的技能域水平。因此活跃的提交者数量并未增长太多，并且新增加的贡献者能引起提交者关注而有望接班人的数量更是凤毛麟角。现有的提交者更愿意将时间花在自己提交的补丁上，而很少优先去关注处理新贡献者提交的补丁，然后再回头清理自己的任务。

如果不能及时得到提交者的关注，新的贡献者会感到沮丧。同样审查阶段也会对提交低质量补丁的人感到沮丧，尤其是重复几轮审查后仍未有太大的改善。提交者还会因为花时间在清理别人的错误而感到沮丧，更糟糕的可能是他们自己引入的错误。作者真诚地相信，几乎每个人都有善良和礼貌的意图，并尽可能帮助他人，但大家从事这项任务的艰巨性给每个人带来了压力，这种压力甚至超出了工作时间，作者已记不清有多少次由此对家人造成的影响。

PostgreSQL是作者参与过的唯一一个开源项目，作者不知道其他项目在多大程度上是否会遇到这些问题，也不知道他们是如何解决这些问题的。尽管作者全职做了15年PostgreSQL开发人员，然后是30年的编程经历，但仍然无法保证提交的测试用例不会在接下来的几个小时或几天里会存在严重风险而需要修改来修复。要么编程是一件很难的事儿，要么我们正在做一件更难的事儿。作者认为后者占大部分，但并不确认。

最后欢迎参与留言评论。