夜雨聆风别再给 PG 装插件了：SQL/PGQ、REPACK、并行 Vacuum 全进内核
正文内容
三十年，从"够用"到"全能"。
2026 年 7 月 16 日，PostgreSQL 19 Beta 2 发布，特性冻结。这不是一次普通的年度迭代——SQL/PGQ 原生图查询、REPACK CONCURRENTLY 在线表重建、并行 Autovacuum、在线 Checksum 启用，每一项都精准命中了生产环境最痛的运维场景。
而就在上个月，pgAdmin 4 一口气爆出 8 个 CVE，其中包括一个 CVSS 近乎满分的 RCE 漏洞。安全圈炸了锅。
一边是内核能力的爆发式增长，一边是工具链的安全警钟——PG 的 2026，比往年都热闹。
PG 19 Beta 2：四个你不该忽略的新特性
1. SQL/PGQ：你的关系库，本来就是个图
这是 PG 19 的头条特性。CREATE PROPERTY GRAPH 一句 DDL，就能在现有关系表上声明一个图模型：
CREATE PROPERTY GRAPH social_graph
VERTEX TABLES (users LABEL person, posts LABEL post)
EDGE TABLES (
follows SOURCE KEY (follower_id) REFERENCES users(id)
DESTINATION KEY (followed_id) REFERENCES users(id) LABEL follows
);然后直接用图语法查：
SELECT*FROM GRAPH_TABLE (social_graph
MATCH (a IS person WHERE a.name ='Alice')
-[IS follows]->(b IS person)-[IS follows]->(c IS person)
COLUMNS (b.name AS friend, c.name AS friend_of_friend)
);底层发生了什么？PG 把图模式重写为标准 JOIN，在你现有的索引和统计信息上跑。没有新存储引擎，没有数据搬迁，没有第二个数据库。
诚实地说：v19 的 SQL/PGQ 是只读的，只支持固定深度遍历。可变长度路径（* / + 量词）要等后续版本。但"你还需要一个专门的图数据库"这个论点，从今天起难讲了十倍。
2. REPACK CONCURRENTLY：维护窗口终结者
表膨胀是每个 DBA 的噩梦。VACUUM FULL 持 ACCESS EXCLUSIVE 锁跑完全程——大表上等于停机。pg_repack 扩展干了十年这件事，但它是第三方 C 扩展，每次大版本升级都要祈祷兼容性。
PG 19 把 REPACK 写进内核：
REPACK TABLE orders;底层逻辑：先建一份表副本，用逻辑解码回放期间的并发写入，最后只持几秒排他锁做文件交换——表全程可读可写。代价只有一个：磁盘需要能装下表的第二份完整副本。几百 GB 的大表，先算磁盘余量再动手。
3. 并行 Autovacuum + 在线 Checksum
ALTER TABLE orders SET (autovacuum_vacuum_index_parallel_workers =4);一张 4000 万行、五个索引的表，Vacuum 时间从 22 分钟降到 7 分钟。但别高兴太早——每个并行 worker 独立吃 maintenance_work_mem，集群级的内存天花板是 autovacuum_max_workers × autovacuum_max_parallel_workers × maintenance_work_mem。不改内存预算就加并行度，OOM Killer 会教你做人。
在线 Checksum 更直接：SELECT pg_enable_data_checksums() 在运行中的集群上启用，不再需要停机。initdb 时忘了开 Checksum 的团队，这次不用重来了。
4. 那些「不起眼」但救命的改动
• WAIT FOR LSN：读写分离架构下，备库查询前等待主库指定 LSN，真正实现"读己之写"的强一致性。以前靠 sleep(100ms) 凑合的日子结束了。 • 默认关闭 JIT：对 90% 的 OLTP 负载，JIT 编译的开销比收益大。这个改动默默救了无数被 JIT 拖慢的查询。 • 64 位 MultiXactOffset：40 亿记录溢出风险从此成为历史。 • EXPLAIN (IO)：直接看 ReadStream / AIO 层的预取命中率，不再靠 BUFFERS 猜。 • pg_plan_advice：优化器终于自己解释"为什么没选那个索引"。
PG 18 你还记得多少？
PG 18 的核心是 AIO 异步 I/O 子系统。io_method = io_uring 让顺序扫描、Bitmap Heap Scan 和 Vacuum 不再阻塞等待磁盘。实测数据：NVMe 上 +3540%，EBS gp3 上 +1520%，"3 倍提升"是官方最理想场景。
其他值得记住的：B-tree Skip Scan（多列索引跳过前导列）、虚拟生成列（默认不占磁盘）、OLD/NEW in RETURNING（一行 SQL 拿到改前改后数据）、原生 OAuth 2.0 认证、UUIDv7、pg_upgrade --swap。
PG 正在吃掉什么？
图数据库：SQL/PGQ 来了，固定深度遍历的场景不用再搞 Neo4j + Kafka + 数据同步三件套。
向量数据库：pgvector 0.8.x 配合 pgvectorscale，千万级向量以内的 RAG 场景，pgvector 的 HNSW + SQL WHERE 过滤组合往往比专用向量库更快。Pinecone 和 Weaviate 的立身之本是十亿级向量和混合搜索，但绝大多数团队连百万级都没到。
数据仓库：pg_duckdb 1.0 百万下载，嵌 DuckDB 向量化引擎进 PG；pg_mooncake 把 PG 推入 ClickBench 前十。TPC-H 查询 2~7 倍加速，一行 SET enable_duckdb = on 搞定。5TB 以下的分析负载，先试试列存扩展，再决定买不买 Snowflake。
安全：别光看新特性，赶紧打补丁
8 月 3 日，pgAdmin 4 爆出 CVE-2026-17566——Import/Export 工具的命令注入漏洞，低权限用户可 RCE。根源是 backslash 转义语义与 PostgreSQL 默认 standard_conforming_strings=on 不一致，一个用了十几年的假设终于被利用。
同期还有 7 个 CVE：CVE-2026-17351（AI 助手 SQL 注入，CVSS 9.0）、CVE-2026-17347（MASTER_PASSWORD_HOOK 命令注入）、CVE-2026-17350（共享连接配置泄露）……
立刻升级 pgAdmin 4 到 9.18。PG 内核方面，5 月发布的 18.4 修复了 11 个 CVE，务必确认当前版本。
升级路线图
| 2026-11-12（不足 3 个月） | ||
还在 PG 14 及以下的，只剩不到 90 天。建议直接跳 PG 18，等 PG 19 GA 后再评估升级。PG 18 的 AIO 已经覆盖了日常 OLTP 最大的性能红利，PG 19 的运维增强可以在下一个维护窗口从容升级。
PostgreSQL 三十岁了。 它没有变成一个"什么都做但什么都做不好"的庞然大物，而是在保持内核克制的前提下，让扩展生态和标准 SQL 能力共同演进。图查询不用装 AGE 了，列存加速 pg_duckdb 一行开关搞定，向量检索 pgvector 开箱即用。
世界最强的开源数据库，正在全面进化。
核心观点：PostgreSQL 19 不是一次功能堆砌式的年度升级，而是通过 SQL/PGQ、REPACK CONCURRENTLY、并行 Autovacuum 三大内核级特性，在"图查询""在线运维"和"自动化治理"三个维度上实现了质的跨越。配合 pgvector + pg_duckdb + pg_mooncake 的扩展矩阵，PG 正在从"关系数据库"蜕变为"数据平台"。
参考的文章：
1. Postgres 19 Learned to Speak Graph[1] - 作者：Bluetick Consultants - SQL/PGQ 深度解读 2. PostgreSQL 18/19 新特性深度解读[2] - 作者：IvorySQL - 从 IO 预取到智能运维 3. You Probably Don't Need a Data Warehouse Yet: Postgres Analytics in 2026[3] - 作者：Reptile Haus - PG 分析能力崛起
引用链接
[1] Postgres 19 Learned to Speak Graph: https://www.bluetickconsultants.com/postgresql-19-sql-pgq-graph-queries[2] PostgreSQL 18/19 新特性深度解读: https://www.cnblogs.com/ivorysql/p/22216525[3] You Probably Don't
