Wise Hustlers — Digital Product & App Development Studio Logo
Get Consultation
By Wise Hustler Admin•9/18/2026•6 min read

PostgreSQL 19 Loses Its Headline Feature Weeks Before Release — Here's What Actually ShippedPostgreSQL 19 在发布前数周痛失主打功能——实际发布内容一览

PostgreSQL 19 Loses Its Headline Feature Weeks Before Release — Here's What Actually Shipped

In the final weeks before PostgreSQL 19's expected general-availability release, the project's maintainers pulled two features that had already been merged and beta-tested: SQL/PGQ property graph queries, reverted on September 7, 2026, and ALTER TABLE ... MERGE/SPLIT PARTITION, reverted on August 27, 2026. Both were cut not because they were unfinished ideas, but because senior contributors judged the code not solid enough to support for the next five years of PostgreSQL's release lifecycle. PostgreSQL 19 itself is still on track for general availability around September or October 2026, currently at beta 3, but it will ship without the graph-query syntax it was expected to headline.在 PostgreSQL 19 预计正式发布前的最后几周,项目维护者移除了两项已经合并并经过 Beta 测试的功能:SQL/PGQ 属性图查询(于 2026 年 9 月 7 日撤回)以及 ALTER TABLE ... MERGE/SPLIT PARTITION(于 2026 年 8 月 27 日撤回)。这两项功能被砍掉并非因为尚未完成,而是因为资深贡献者认为其代码不够稳健,无法支撑 PostgreSQL 未来五年的发布周期。PostgreSQL 19 本身仍按计划于 2026 年 9 月或 10 月左右正式发布,目前处于 Beta 3 阶段,但它在发布时将不会包含原定作为主打功能的图查询语法。

What happened, in order事件回顾

PostgreSQL follows an annual major-release cadence, and 19 has been moving through the normal cycle: beta 1 on June 4, 2026, beta 2 in July, and beta 3 on August 13, 2026 (which also fixed 28 security-related issues and over 110 bugs across the whole supported line, per the project's own release announcement). Beta 3 was expected to be close to feature-complete, with only bug fixes and polish left before release candidates.PostgreSQL 遵循年度大版本发布节奏,19 版本一直按正常周期推进:6 月 4 日发布 Beta 1,7 月发布 Beta 2,8 月 13 日发布 Beta 3(据项目发布公告称,该版本还修复了整个受支持系列中的 28 个安全相关问题和 110 多个漏洞)。Beta 3 原本预计已接近功能完备,发布候选版本(RC)之前仅剩下漏洞修复和润色工作。

That changed on August 25, 2026, when core contributor Robert Haas asked the pgsql-hackers mailing list a blunt question: of the features that had gone through unusually heavy post-merge patching, were any of them actually not ready? Six were named as candidates for discussion.2026 年 8 月 25 日情况发生了变化,核心贡献者 Robert Haas 向 pgsql-hackers 邮件列表提出了一个直截了当的问题:在那些合并后经历了异常繁重补丁工作的特性中,是否有哪一个实际上尚未准备好?随后有六项特性被列为讨论对象。

Two failed the test:其中两项未通过评估:

  • `ALTER TABLE ... MERGE/SPLIT PARTITION` was reverted on August 27, removing 14 commits. The stated reason was "multiple design issues which are too late to address in this release cycle."`ALTER TABLE ... MERGE/SPLIT PARTITION` 于 8 月 27 日被撤回,移除了 14 个提交。给出的理由是“存在多个设计问题,在此发布周期内已无法解决”。
  • SQL/PGQ (SQL Property Graph Queries) — the ability to run GRAPH_TABLE queries and define CREATE PROPERTY GRAPH views over existing relational tables, standardized in SQL:2023 — was reverted on September 7, removing 47 commits: the entire feature plus every fix built on top of it since it landed.SQL/PGQ(SQL 属性图查询)——即运行 GRAPH_TABLE 查询并在现有关系表上定义 CREATE PROPERTY GRAPH 视图的能力(已在 SQL:2023 标准中标准化)——于 9 月 7 日被撤回,移除了 47 个提交:这不仅包含了整个功能,还包括了自其落地以来在其基础上构建的所有修复。

Tom Lane, one of PostgreSQL's longest-tenured contributors, put the risk plainly on the mailing list: "At this point I'd be willing to bet dinner that if we ship it in v19 there will be post-release bug discoveries that are unfixable until v20." Tom Kincaid, EDB's senior VP of software engineering, publicly confirmed PGQ would not be part of the 19 release. The trade press covered it as a story about restraint — The Register's headline framed it as the feature failing "the 'would you ship this?' test" — which is a fair summary of what actually happened: a feature that worked in demos wasn't trusted to work unattended in production for years, so it got pulled rather than shipped and patched later.PostgreSQL 最资深的贡献者之一 Tom Lane 在邮件列表中直言不讳地指出了风险:“此时我敢打赌,如果我们将其放入 v19 发布,后续发现的 Bug 将在 v20 之前无法修复。”EDB 软件工程高级副总裁 Tom Kincaid 公开确认 PGQ 将不会包含在 19 版本中。行业媒体将其报道为关于克制的故事——《The Register》的标题将其描述为未能通过“你会发布它吗?”测试的功能——这确实准确概括了实际情况:一个在演示中可用的功能,因无法被信任在生产环境中长期稳定运行,最终被移除,而不是强行发布后再打补丁。

Because PostgreSQL major versions are supported for roughly five years and a SQL-surface feature like PGQ is hard to change once applications depend on it, the project's norm is that it's cheaper to delay a feature by a year than to ship something that might need a breaking fix in a point release. The earliest PGQ could now land is PostgreSQL 20, expected around September 2027.由于 PostgreSQL 大版本支持周期约为五年,且像 PGQ 这样涉及 SQL 表面的功能一旦被应用程序依赖就很难更改,因此该项目的惯例是:推迟一年发布功能,比发布一个可能需要在点版本中进行破坏性修复的功能代价更小。PGQ 最早可能在 PostgreSQL 20 中落地,预计时间约为 2027 年 9 月。

What's still actually in PostgreSQL 19PostgreSQL 19 实际包含的内容

The revert doesn't erase the rest of the release. Based on the beta release notes, PostgreSQL 19 still includes:撤回操作并未抹去该版本的其余内容。根据 Beta 版发布说明,PostgreSQL 19 仍然包含:

  • `REPACK`, a new command that folds together what VACUUM FULL and CLUSTER used to do separately — reclaiming disk space and reorganizing table storage — with a CONCURRENTLY option that avoids blocking reads and writes while it runs.`REPACK`:一项新命令,将 VACUUM FULL 和 CLUSTER 原本分别执行的操作(回收磁盘空间和重组表存储)合并在一起,并提供 CONCURRENTLY 选项,以避免在运行时阻塞读写操作。
  • Parallel autovacuum, which can now use multiple worker processes to vacuum a single table's indexes, plus a new pg_stat_autovacuum_scores view that shows which tables autovacuum considers most in need of attention.并行自动清理(Parallel autovacuum):现在可以使用多个工作进程来清理单个表的索引,此外还新增了 pg_stat_autovacuum_scores 视图,用于显示自动清理认为最需要关注的表。
  • Sequence values in logical replication, and the ability to raise wal_level to replica and enable logical replication without a full server restart.逻辑复制中的序列值支持,以及无需重启整个服务器即可将 wal_level 提升至 replica 并启用逻辑复制的能力。
  • Online toggling of data checksums — turning checksums on or off without taking the server down.数据校验和(data checksums)的在线切换——无需停机即可开启或关闭校验和。
  • `pg_plan_advice`, a new module for pinning down query plans, and eager aggregation improvements aimed at analytical queries.`pg_plan_advice`:一个用于锁定查询计划的新模块,以及针对分析型查询的预聚合优化。
  • Reported gains of up to roughly 2x on insert throughput in workloads with foreign-key checks, per the beta release notes — a vendor/project-reported figure from the release notes themselves, not an independently reproduced benchmark, so treat it as a claim to verify against your own workload rather than a guarantee.据 Beta 版发布说明,在涉及外键检查的工作负载中,插入吞吐量最高提升了约 2 倍——这是发布说明中由供应商/项目方报告的数字,而非独立复现的基准测试结果,因此请将其视为需要针对自身工作负载进行验证的声明,而非保证。

None of that is small. Parallel autovacuum and online REPACK in particular address two of the most common operational headaches in any Postgres-backed production system: vacuum falling behind on large, busy tables, and needing a maintenance window to reclaim bloat. The graph-query removal is the story because it's unusual — features rarely get pulled this late — not because the release is thin without it.这些改进都不容小觑。特别是并行自动清理和在线 REPACK,解决了 Postgres 驱动的生产系统中两个最常见的运维痛点:大型繁忙表上的清理任务滞后,以及需要维护窗口来回收膨胀空间。图查询功能的移除之所以成为新闻,是因为这种情况罕见——功能很少在如此晚的阶段被撤回——而不是因为没有它该版本就变得单薄。

What this changes这带来的影响

For a team running Postgres in production today, close to nothing changes immediately. This site's own stack (src/lib/db.ts, per this repo's CLAUDE.md) runs a Prisma client against Postgres with slow-query logging, and nothing here requires action before PostgreSQL 19 ships. The practical items worth tracking:对于目前在生产环境中运行 Postgres 的团队来说,几乎没有任何直接影响。本站自己的技术栈(根据本仓库的 CLAUDE.md,路径为 src/lib/db.ts)运行着带有慢查询日志的 Prisma 客户端连接 Postgres,这里没有任何内容需要在 PostgreSQL 19 发布前采取行动。值得关注的实际事项包括:

  • If you were planning around SQL/PGQ, drop that plan. It's not in 19, full stop, and won't be until at least PostgreSQL 20 in a year. If you need graph-shaped queries against relational data now, you're still writing recursive CTEs or reaching for a dedicated graph store.如果你曾围绕 SQL/PGQ 进行规划,请放弃该计划。它不会出现在 19 版本中,确定无疑,并且至少要等到一年后的 PostgreSQL 20。如果你现在需要针对关系数据进行图查询,你仍然需要编写递归 CTE 或选择专用的图数据库。
  • If large-table vacuum lag or bloat-driven maintenance windows are a recurring pain, parallel autovacuum and online REPACK are worth testing against a beta or RC build (Amazon RDS already has PostgreSQL 19 beta 3 in its preview environment) before the version reaches your production upgrade queue.如果大表清理滞后或因空间膨胀导致的维护窗口是长期困扰,那么在版本进入生产环境升级队列之前,值得使用 Beta 或 RC 构建版本(Amazon RDS 的预览环境中已经有 PostgreSQL 19 Beta 3)来测试并行自动清理和在线 REPACK 功能。
  • Read release notes, not headlines, before any major-version upgrade. This cycle is a concrete reminder that beta feature lists change — a feature present in beta 2 was gone by beta 3's successor. Don't design a migration around a not-yet-released capability until it survives to a release candidate.在大版本升级前,请阅读发布说明,而不是标题。这个周期是一个具体的提醒:Beta 版的功能列表会变动——Beta 2 中存在的功能在 Beta 3 的后继版本中可能就会消失。在功能进入发布候选版本之前,不要围绕尚未发布的能力进行迁移设计。
  • The process itself is the more durable lesson. A team with commit rights and a beta already in the wild still pulled 47 commits of a marquee, standards-track feature two weeks before likely release, in public, with a named engineer staking a dinner bet on the reasoning. That's a data point on how PostgreSQL's governance treats "works in beta" versus "safe to support for five years" — worth keeping in mind the next time a database migration guide promises a not-yet-GA feature will "just be there."这一过程本身是更持久的教训。一个拥有提交权限且 Beta 版已在广泛使用的团队,在发布前两周公开撤回了一个标准跟踪主打功能的 47 个提交,并由一名工程师以晚餐为赌注解释了原因。这体现了 PostgreSQL 的治理机制如何看待“在 Beta 中可用”与“可支撑五年”之间的区别——下次当数据库迁移指南承诺某个尚未 GA 的功能“届时就会有”时,请务必记住这一点。

Wise Hustlers builds and operates production systems on Postgres, including schema, query, and migration work — see our services if that's relevant to your stack.Wise Hustlers 在 Postgres 上构建并运维生产系统,包括模式设计、查询优化和迁移工作——如果这与你的技术栈相关,请查看我们的服务。

Sources来源

Related articles相关文章

Cookie Preferences

We use tracking cookies to personalize content, analyze server traffic metrics, and optimize your conversion experience.