从不敲代码到 PostgreSQL 贡献者之路

本文整理于 HOW 2026 演讲内容，演讲者：类延良，PostgreSQL contributor。

我为 PostgreSQL 14、15、16、18 都做过贡献。说白了，这个“贡献”主要就是提 Bug。实际上，我最早是为 PG 13 提的 Bug，所以我的名字出现在了 PG 14.0 的 Release Notes 里。今年 1 月（其实是去年 12 月），我又在 PG 18.1 上发现了一个 Bug，预计今年 9 月 PG 19 发布的时候，我的名字就会出现在 PG 19.0 的 Release Notes 里。

下面我从四个方面来聊：一是贡献者介绍，二是为 PG 做贡献的途径，三是有什么好处，四是重点分享我做贡献的具体经历。

一、贡献者介绍

严格来讲，大家别看我在宣传页上写着“Contributor”，其实我不是官方认定的那种核心贡献者。PostgreSQL 对贡献者有严格的认定标准，官方维护一份公开的贡献者名单，分 Core Team、Major Contributors、Significant Contributors、Past Major Contributors、Past Contributors 等层级。那个名单在 postgresql.org/community/contributors/ 上可以查到。

二、为 PG 做贡献的途径——提 Bug 的完整流程

我主要做的是提缺陷（Bug），流程大致如下：

1. 注册账号

首先要在 postgresql.org 上注册或登录一个账户。注册过程中有人机验证（ReCAPTCHA），在国内访问时验证码经常加载不出来，需要想办法。我当时是请 IvorySQL 社区的朋友帮忙在国外注册的，当然也不排除有其他手段。

2. 提交 Bug

通过 postgresql.org/account/submitbug/ 提交，提交后会生成一个 Bug 编号。

3. 跟踪后续动态

后续可以通过两种方式跟踪：

• 查看注册邮箱的通知；
• 直接访问 pgsql-bugs 邮件列表，按年月定位自己提交的 Bug。

说起来，我之前做了很多年 Oracle DBA，也用过 Oracle 的 Support 平台（以前叫 MOS，现在叫 My Oracle Support）。那个平台的正常访问是需要付费的，对比下来，PG 社区不用花钱就能提 Bug，门槛低了很多。

三、参与贡献有什么好处？

社区会为贡献者提供实物纪念品作为激励。

最典型的是纪念币。每个大版本会发行一款纪念币，大概 5 号电池（AA 电池）那么大。我当时为 PG 15 做了贡献，后来收到了一封邮件，大意是：“感谢你为 PostgreSQL 15 做出贡献，我们想送你一枚纪念币，请回复邮寄地址。如果你拒绝礼物也请告知。”我当然不拒绝，就填了地址。

负责分发的是 Mark Wong（这次大会他也来了）。他告诉我已经发出了，给了美国邮政的物流单号。但后来我一直查，包裹始终停在首都国际机场。我猜测是因为我没有提供身份证号，没法清关。最后我也没收到那枚币。

所以后来，瀚高股份的 IvorySQL 社区工作人员就负责在国内分发 PostgreSQL 贡献者纪念币，解决了清关问题。

另外我还收到过 FerretDB 从拉脱维亚寄来的广告衫，那次我提供了身份证号，就顺利收到了。

四、我做贡献的具体经历

在不碰代码的前提下找到 PostgreSQL 的 Bug，其实并不容易。我个人的职业经历是 Oracle DBA，以及数据同步（逻辑复制）软件的产品经理。我的发现路径主要有两条：

1. 从整理参数文档入手

我在系统化整理 PG 13 的配置参数时，发现 PG 官方文档缺乏像 Oracle 那样清晰的表格化说明。Oracle 的文档会明确列出：参数名、数据类型、取值范围（极值）、是否重启生效、单位（KB/MB）、是否允许备库不同等。PG 13 虽然有表格，但不够系统。

于是我逐一手动翻阅文档，并在 pg_settings 视图里验证每个参数的类别（Category）、极值、是否重启生效等。结果发现：某个参数在 pg_settings 里显示的类别，和官方文档描述的不一致。也就是说，查询结果与文档不符。

我提了 Bug，社区确认了，修复后我的名字就出现在了 PG 14.0 的 Release Notes 里。

2. 从新特性入手

新特性容易考虑不周，是发现 Bug 的好切入点。

今年 2 月（实际上是去年 12 月），我在做逻辑复制软件相关工作，需要关注 DDL 支持。PG 18 新增了为 NOT NULL 约束命名的能力，并且允许后续修改约束名。我就测试了一下这个改名功能。

执行改名操作后，客户端返回“修改成功”，但再次查询系统表时，发现约束名根本没变，状态不一致。这显然是个 Bug。我提了之后被确认了，后续由 EDB 公司的工程师修复了。

3. 一个额外痛点：序列归属查询太复杂

再讲一个我们在做逻辑复制软件时遇到的痛点。PostgreSQL 里，不同 Schema 下可以有同名的序列（Sequence）。在逻辑复制或数据同步场景中，我们必须知道：某个表的某一列，到底引用的是哪个 Schema 下的哪个序列？

如果名字都相同，怎么快速区分？

Oracle 有直接的数据字典视图（比如 dba_tab_cols 等），一条 SQL 就能查出来。但 PG 就很费劲。查询结果会受当前 search_path 影响，很容易搞混。

我们最后是写了一段很长的多表关联 SQL，用到了 pg_attribute、pg_class、pg_depend，还要解析 attidentity 或默认值表达式（比如 nextval('schema.seq')）才能定位出来。代码长到占了很多行。

虽然最终能查出来，但我觉得，从数据库管理工具的易用性来看，PG 在这个功能上确实不如 Oracle 方便。这也算是我在使用过程中感受到的一个真实痛点。

以上就是我从不敲代码到成为 PostgreSQL 贡献者的全部经历。感谢为 PostgreSQL 做出过贡献的所有人！