三月份，Lucas Draescher 向 PostgreSQL 提交了他的第一个补丁，修复了使用 io_method=io_uring 时文件描述符泄漏的问题。补丁干净、动机明确，已经迭代到第三版。然后它在 commitfest 里静静躺了两个月——零评审。
这不是例外，这是常态。PostgreSQL 靠志愿者运转，核心提交者人数有限，补丁队列却很长。一个写得不错的补丁等上几个月没人看，在社区里不算新闻。
补丁排队到底有多长
PostgreSQL 用 Commitfest Management App 管理补丁流程。每个提交周期（commitfest）会收录一批补丁，由社区评审、修改、最终由 committer 合入。
现实情况：补丁数量远超有能力评审的人。提交者（committer）需要既懂代码又懂项目规范，还要花大量时间在自己不熟悉的领域做审查。结果是——大量补丁处于 "Needs Review" 状态，等待有人哪怕只是跑一下测试、读一下代码。
Lucas 的补丁是一个典型场景：
- 问题明确：
io_uring模式下 fd 泄漏 - 修复范围小，改动清晰
- 作者已经根据反馈改了三轮
它需要的不是一位核心提交者做最终裁决，而是任何一位有经验的开发者说"我读了代码，逻辑没问题，测试通过"。这一步卡住了。
评审者从哪里来
PostgreSQL 社区有一个常被忽视的事实：评审者不需要是 committer。评审者的工作是：
- 读补丁，理解它要解决什么问题
- 在本地编译并运行相关测试
- 检查代码风格、边界条件、文档是否同步
- 在 commitfest 页面写下评审意见
任何人都可以做这件事。你不需要对 PostgreSQL 内部了如指掌——补丁作者和 committer 会补上你遗漏的部分。你只需要认真读、认真跑、认真写。
实践：从浏览到评审一条补丁
下面是一个完整的流程，你可以今天就动手试。假设你想评审 Lucas 的那个 io_uring fd 泄漏补丁。
第一步：找到补丁
打开 Commitfest Management App，浏览当前开放的 commitfest：
# 用 curl 快速查看当前 commitfest 列表（也可以直接浏览器打开）
curl -s https://commitfest.postgresql.org/ | grep -oP 'action=open[^"]*' | head -5
或者直接访问 https://commitfest.postgresql.org/，进入当前开放周期，搜索关键词 io_uring 或按作者名 Lucas Draescher 过滤。
第二步：下载并编译补丁
# 克隆 PostgreSQL 源码（如果还没有）
git clone https://git.postgresql.org/git/postgresql.git
cd postgresql
# 切到目标分支（通常是 master，补丁说明里会写）
git checkout master
# 从 commitfest 页面下载补丁文件（假设文件名为 v3-0001-fix-io-uring-fd-leak.patch）
# 放到源码根目录后应用
git apply v3-0001-fix-io-uring-fd-leak.patch
# 编译（启用 io_uring 支持需要 Linux 5.1+ 和 liburing）
./configure --enable-debug --enable-cassert
make -j$(nproc)
make install
# 运行相关测试
make check
如果 git apply 报错，说明补丁基于旧版本，先看补丁的基准 commit，用 git checkout <base-commit> 切过去再应用。
第三步：写评审意见
评审不需要写成论文。一个有效的评审模板：
评审者: <你的名字>
日期: <今天>
补丁: fix io_uring fd leak (v3)
1. 补丁是否解决了声称的问题？
- [是/否/不确定] + 简短说明
2. 编译和测试结果
- 平台: <OS, kernel version>
- make check: <PASS/FAIL>
- 手动测试: <描述你做了什么，结果如何>
3. 代码审查
- 逻辑是否正确？
- 是否有边界条件遗漏？
- 代码风格是否符合项目惯例？
- 注释和文档是否需要更新？
4. 其他建议
- <任何你觉得值得提的>
把这段内容贴到 commitfest 页面对应补丁的评论区，状态从 "Needs Review" 改为 "Ready for Committer"（如果你认为没问题）或保留并标注你的评审状态。
一个更小的起点
如果你觉得评审内核 I/O 相关补丁门槛太高，可以从更简单的开始。commitfest 里总有一批小补丁——文档修正、错误信息改进、边缘 case 修复。挑一个你理解的领域，花一两个小时读完、跑完、写完评审，你就从用户变成了贡献者。
PostgreSQL 的补丁评审瓶颈不是技术问题，是人数问题。每个被评审的补丁都在缩短队列，也在给作者一个信号：有人在乎你做的事。