大多数 PostgreSQL 大会的参会者以用户和 DBA 为主——听演讲、学调优、拿最佳实践回家。PGConf.dev 不一样。它吸引的是贡献者和社区核心成员，这意味着你带着 Patch 去现场，真的有人坐下来帮你 Review。
六轨并行的一天
Robert Haas 负责组织周二的内容，横跨六个 Track。六轨意味着同一时段有六场不同方向的深度分享并行进行——从核心引擎改动到扩展生态，从安全机制到性能回归测试，选择多到需要提前做功课。这种密度只有在贡献者密集的场合才撑得住：演讲者本身往往就是某个特性的 Author，Q&A 直接变成设计讨论。
Talk Selection 与社区把关
Jacob Champion 在 Talk Selection Committee 上，Phil Alger、Manni Wood 等人也在幕后承担了大量工作。选稿委员会的作用不只是筛好坏——它决定了大会的技术重心偏向哪里。一个被选中的 Patch Review 话题，可能直接推动某个长期悬而未决的 Commit。这就是 PGConf.dev 和普通用户大会的根本差异：议程本身就是开发路线图的缩影。
在现场把 Patch 推进一步
PGConf.dev 最实际的价值：面对面 Review。邮件列表上的 Review 周期可能拖几周甚至几个月，但在会场走廊或 Unconference 环节里，十分钟对话就能澄清设计意图、敲定边界条件。如果你有正在 CF（Commitfest）里等待 Review 的 Patch，带上一份简洁的 diff 和测试结果去参会，效率远超纯线上沟通。
下面是一个最小化的 PostgreSQL Patch 提交流程示例——从生成 diff 到注册 Commitfest，你可以在本地直接跑：
# 1. 从官方仓库拉取最新代码
git clone https://git.postgresql.org/git/postgresql.git
cd postgresql
# 2. 在新分支上做改动（示例：给某个日志消息加上下文信息）
git checkout -b add-log-context
# 修改代码后……
git add src/backend/utils/error/elog.c
git commit -m "Add context field to errlog for better traceability"
# 3. 生成符合 PG 社区规范的 diff（context diff 格式）
git diff HEAD~1 --src-prefix=a/ --dst-prefix=b/ > add-log-context.patch
# 4. 检查 patch 是否能干净应用
git checkout master
git apply --check add-log-context.patch
# 如果没有报错，说明 patch 基于最新 master 生成，冲突风险低
# 5. 跑一遍基础回归测试，确保没有破坏现有功能
make -j4 && make check
# 6. 提交到 Commitfest
# 打开 https://commitfest.postgresql.org/
# 选择当前开放的 Commitfest，注册新 Patch Entry
# 填写标题、作者、patch 文件路径，关联邮件列表讨论链接
几个实操要点：
- diff 格式：PG 社区习惯用 context diff（
git diff -U3），不是默认的 unified diff。--src-prefix和--dst-prefix保持a/b/是社区约定。 - 测试先行：
make check只跑核心回归。如果你的改动涉及特定模块，加跑src/test/modules/下对应的专项测试。 - Commitfest 注册：每个 Patch 必须挂在一个开放的 CF 下。CF 按月滚动，错过窗口就等下一个——这也是为什么现场 Review 能帮你抢时间。
给想去参会或贡献的人几条建议
- Patch 不成熟也值得带：半成品 Patch 在走廊讨论里往往收获最大，因为设计方向的问题比代码细节更难在邮件列表里高效解决。
- 提前看议程做选择：六轨并行，不可能全听。优先选和你当前工作直接相关的 Track，剩下的时间留给 Unconference 和走廊对话。
- 认识 Committer：PGConf.dev 是少数你能直接和 Active Committer 面对面聊设计取舍的场合。一个十分钟的现场解释，可能省掉邮件列表上三轮来回。
- 从 Review 别人的 Patch 开始：如果还没有自己的 Patch，去 Commitfest 里挑一个感兴趣的 Entry 做 Review，这本身就是被认可的贡献路径。
PGConf.dev 的核心不是演讲本身，而是把写代码的人和审代码的人放在同一个房间里。Patch 在邮件列表上可能沉睡半年，在现场可能一天就拿到明确的下一步方向。如果你在 PostgreSQL 上有想推进的东西，这个大会是最短的路径。