PGConf.dev 2026：PostgreSQL 三十周年，社区与技术都在经历关键转折

预计阅读时间：15 分钟

2026 年对 PostgreSQL 是个特殊年份——项目诞生整整三十年。今年的 PGConf.dev 回到了温哥华，这场以贡献者和内核开发者为核心的小型会议，比任何其他 PostgreSQL 大会都更"真实"：邮件列表里那些只出现在 commit 记录中的名字，突然就站在你旁边，端着咖啡和你讨论 patch 的边界条件。

但三十周年不只是庆祝。从会议的技术议题来看，PostgreSQL 正同时面对几个方向的结构性压力：内核功能的企业级缺口、贡献者生态的规模瓶颈、以及 AI 工具对开发流程的冲击。下面挑几个对一线开发者影响最大的议题展开。

内置 REPACK CONCURRENTLY：DBA 等了多年的在线去膨胀

表膨胀（bloat）是 PostgreSQL 运维的老问题。VACUUM FULL 能回收空间，但持有排他锁，大表上可能阻塞访问数小时。社区长期依赖 pg_repack 和 pg_squeeze 这类外部扩展来"在线"重建表——前者用触发器追踪并发变更，后者基于 WAL。

Álvaro Herrera 在会上介绍了 PostgreSQL 19 计划引入的 REPACK CONCURRENTLY，把在线重建表的能力收进内核。它本质上是合并了 VACUUM FULL 和 CLUSTER 的目标，同时允许大部分操作期间正常读写。

对 DBA 来说，这意味着不再需要安装额外扩展、不再担心触发器追踪的额外开销、也不再受限于扩展与内核版本兼容性的牵绊。先看当前 pg_repack 的典型用法，再对比未来内置方案的预期形态：

# 当前方案：安装 pg_repack 扩展后在线重建表
# 前提：目标表必须有主键或唯一索引
psql -d mydb -c "CREATE EXTENSION pg_repack;"

# 对指定表执行在线 repack（不持排他锁）
pg_repack -d mydb -t orders --no-order

# 按特定索引顺序重建（类似 CLUSTER）
pg_repack -d mydb -t orders -i idx_orders_created_at

-- PostgreSQL 19 预期内置语法（基于会议信息推测，具体语法以正式发布为准）
-- 在线重建表，不阻塞读写
REPACK CONCURRENTLY TABLE orders;

-- 按索引顺序在线重建
REPACK CONCURRENTLY TABLE orders USING INDEX idx_orders_created_at;

关键差异：内核实现可以直接利用 WAL 机制追踪并发变更，不需要触发器中间层，也不需要扩展的 shadow table 结构。这在大表、高并发场景下应该更稳定、更高效。

全局索引：用户想要，内核很难给

分区表上跨分区唯一约束是 Oracle 迁移用户的常见痛点。PostgreSQL 当前要求唯一约束必须包含分区键，这意味着你无法在分区表上直接建一个只基于非分区列的唯一索引。

Dilip Kumar 展示了全局索引（Global Index）的实验性实现：索引元组同时存储 TID 和分区标识符，能跨分区定位行。但 Unconference 讨论暴露了三个硬骨头：

VACUUM 扩展性：跨分区清理死元组，需要访问多个分区的可见性信息
DDL/重写复杂度：ATTACH/DETACH PARTITION、REINDEX、VACUUM FULL 都要同步更新全局索引
锁竞争：跨分区唯一性检查可能需要更宽的索引锁，引入新的死锁风险

一个有趣的替代思路是"全局唯一索引"——不改变现有索引存储结构，只在 INSERT/UPDATE 时跨分区检查唯一性。作者 Cary Huang 本人也是 2023 年那版 patch 的共同作者。这个方案绕开了 VACUUM 和重写问题，但 INSERT/UPDATE 更慢，且跨分区检查本身也可能死锁。

-- 当前 PostgreSQL 的限制：唯一约束必须包含分区键
CREATE TABLE orders (
    id          BIGINT,
    region_id   INT,
    order_no    TEXT,
    created_at  TIMESTAMP
) PARTITION BY LIST (region_id);

-- 这个可以（包含了分区键 region_id）
CREATE UNIQUE INDEX idx_orders_unique ON orders (order_no, region_id);

-- 这个不行（order_no 跨分区唯一，但不含分区键）
-- CREATE UNIQUE INDEX idx_orders_global ON orders (order_no);
-- ERROR: unique constraint in partitioned table must contain all partition key columns

-- 实际 workaround：在每个分区上建局部唯一索引 + 应用层保证跨分区唯一
-- 或用触发器/应用逻辑模拟全局唯一性检查

目前没有清晰共识。如果你正在做 Oracle 到 PostgreSQL 的迁移，遇到跨分区唯一约束需求，短期内还是要在应用层或触发器层面解决。

pg_plan_advice：给执行计划一个"锚点"

执行计划不稳定是 PostgreSQL 在生产环境中的经典痛点——统计信息波动、成本估算偏差都可能导致计划突然变差。Robert Haas 介绍了 PostgreSQL 19 计划加入的 pg_plan_advice contrib 模块，思路是让 planner 既生成计划，也接受一种轻量的"建议语言"来约束关键决策。

-- pg_plan_advice 预期用法示例（基于会议介绍，具体语法以正式发布为准）

-- 步骤 1：捕获已知良好的计划建议
SELECT pg_plan_advice_capture(
    'SELECT * FROM orders o JOIN customers c ON o.customer_id = c.id WHERE c.region = ''APAC'''
);
-- 返回类似：'join_order(o,c):hash(o):seq_scan(c):gather_merge'

-- 步骤 2：将建议绑定到查询，让 planner 优先遵循
SELECT pg_plan_advice_set(
    'SELECT * FROM orders o JOIN customers c ON o.customer_id = c.id WHERE c.region = ''APAC''',
    'join_order(o,c):hash(o):seq_scan(c):gather_merge'
);

-- 步骤 3：执行查询时 planner 会禁用与建议冲突的路径
-- 如果统计信息变化导致 planner 想 swap join 顺序，建议会阻止它

这和 Oracle 的 outline / SQL profile 思路类似，但更轻量。它不是硬性 hint——planner 仍然在建议允许的空间内做成本比较。Robert 也提到未来可能扩展到基数提示、聚合策略控制，甚至基于历史数据自学习生成建议。

如果你现在就在对抗计划不稳定问题，可以先用 pg_hint_plan 扩展做硬性 join/scan hint，同时关注 pg_plan_advice 的进展——后者在灵活性和可维护性上可能更优。

CommitFest 的规模危机：72% 的 patch 没有 reviewer

Andreas Scherbaum 和 Jimmy Angelakos 用数据说明了 PostgreSQL 开发流程正在承受的压力：

指标	2015 年	2025 年
Patch 数量	418	885
作者数量	125	272
首次贡献者回归率	~73%	~36–37%
中位 commit 等待时间	—	80 天
90 分位 commit 等待时间	—	256 天

更严峻的是：72.1% 的 "Needs Review" patch 没有分配 reviewer；当前 CommitFest 中 196 个 patch 的 reviewer 数为零。Top 5 committer 承担了 55% 的 commit，Top 10 承担 74%。

# 你可以自己查看当前 CommitFest 的 reviewer 状态
# 访问 https://commitfest.postgresql.org/
# 或用 curl 快速统计 open patch 数量

curl -s https://commitfest.postgresql.org/action/commitfest.php?id=45 |
  grep -c "Needs Review"

# 如果你想开始做 review，最简单的入口：
# 1. 在 CommitFest 网站注册账号
# 2. 挑一个 "Needs Review" 且无 reviewer 的 patch
# 3. 下载 patch，编译测试，在邮件列表回复 review 意见
# 4. 不需要是 committer——任何人都可以做 reviewer

# 快速测试一个 patch 的最小步骤
git clone https://git.postgresql.org/git/postgresql.git
cd postgresql
git checkout master
curl -sO https://commitfest.postgresql.org/patch/XXXX.patch
git apply XXXX.patch
make -j4 && make install
make check  # 运行回归测试

贡献者流失率高是最大的长期风险。如果你用 PostgreSQL 并且有 C 语言基础，做 patch review 是对项目最直接、最有效的贡献方式——比写博客、做演讲都更稀缺。

TDE：还在辩论，但方向在收敛

透明数据加密（TDE）是合规场景的刚需，但 PostgreSQL 内核至今没有内置方案。Alistair Turner 和 Zsolt Parragi 主持的讨论再次暴露了核心分歧：WAL 级加密 vs 文件级加密、密钥管理接口、LSN 作为 IV 的安全性、扩展实现 vs 内核实现。

Peter Eisentraut 分享了 EDB 的 TDE 实现经验，实际工程中的认证加密、SLRU 加密、多租户场景都远比设计文档上复杂。标题说"Stop Debating, Start Implementing"，但讨论本身证明共识仍然遥远。

如果你现在就需要静态加密，实用路线是：

# 方案 A：文件系统层加密（LUKS），最简单，不依赖 PostgreSQL 特性
cryptsetup luksFormat /dev/sdb
cryptsetup luksOpen /dev/sdb pg_encrypted
mkfs.ext4 /dev/mapper/pg_encrypted
mount /dev/mapper/pg_encrypted /var/lib/postgresql/data

# 方案 B：云平台加密卷（AWS EBS encryption / Azure Disk Encryption）
# 在创建卷时启用加密，PostgreSQL 完全无感知

# 方案 C：如果需要列级/表级加密，在应用层实现
# Python 示例：用 pgcrypto 扩展做列级加密
psql -c "CREATE EXTENSION pgcrypto;"
psql -c "INSERT INTO sensitive_data (id, secret_field)
         VALUES (1, encrypt('敏感内容', '密钥', 'aes'));"
psql -c "SELECT decrypt(secret_field, '密钥', 'aes') FROM sensitive_data WHERE id = 1;"

内核 TDE 短期内不会落地，合规需求还是得靠外部方案。

AI 进入 PostgreSQL 开发：最该做的事是帮 review

Unconference 的 "Code, AI and You" 讨论触及了一个现实问题：AI 已经在改写整个行业的开发流程，PostgreSQL 社区迟早要定义 AI 辅助代码在 upstream 中的位置。

但最有价值的洞察不是"让 AI 写代码更快"，而是：PostgreSQL 的瓶颈不在写代码，在 review 代码。72% 的 patch 没有 reviewer——如果 AI 能做初步的 patch 分类、风格检查、测试覆盖度分析、甚至生成 review 摘要，它补的是人最不愿意做但最需要做的环节。

PGNexus.AI 平台也在尝试用 AI Agent 做邮件列表摘要、patch 分析和跨语言信息聚合，目标是让中国和其他非英语社区的反馈更容易回流到 upstream。

三十年：人的项目

三十周年圆桌上，Jolly Chen 分享了她 1994 年在 Berkeley 读研究生时给 Postgres 加 SQL 支持的故事——那一步直接催生了今天我们用的 PostgreSQL。Bruce Momjian 在温哥华海滨切蛋糕，日落、山脉、港口作为背景，那一刻你意识到这个数据库背后是持续三十年的人际连接。

会议的价值也在这里。走廊里五分钟的讨论可能比一小时演讲更有启发性；晚餐时在麒麟饭店用普通话点菜的中国开发者，和来自十几个国家的贡献者一起吃到了正宗中餐——这些场景不会出现在任何 commit 记录里，但它们是项目持续运转的燃料。

实践检查清单

如果你读完这篇文章想做点什么，以下是最直接的入口：

做一次 patch review：去 CommitFest 网站找一个零 reviewer 的 patch，下载、编译、测试、在邮件列表回复。这是目前最稀缺的贡献。
关注 PG19 新特性：REPACK CONCURRENTLY 和 pg_plan_advice 都在计划中，跟踪邮件列表讨论，提前评估对你的运维场景的影响。
评估分区策略：如果你有跨分区唯一约束需求，现在就要在应用层或触发器层做设计，全局索引短期内不会可用。
静态加密选路径：合规需求用 LUKS 或云平台加密卷解决；列级加密用 pgcrypto；不要等内核 TDE。
考虑参加 PGConf.dev 2027：明年蒙特利尔，这场会议的密度和交流质量值得专程去。

PostgreSQL 三十年了。代码在进化，社区在扩张，但最根本的挑战还是一样的：足够多的人愿意花时间理解别人的代码、给出反馈、把好想法推进去。如果你是用户，你最有价值的贡献可能不是写新功能，而是 review 一个等待了 80 天的 patch。