PostgreSQL 19 的首个 Beta 版本发布在即。随着特性冻结（Feature freeze）于 4 月 8 日截止，PG19-Final 提交狂欢（Commitfest）于 4 月 9 日关闭，pgsql-hackers 邮件列表上的发行说明（Release Notes）草案也已基本定型。各大媒体的前瞻报道大都会把 SQL/PGQ 图查询作为头条特性来大写特写。但我偏不。
相比于图查询语法，以下四个 PostgreSQL 19 的新变化对运维工作的影响要深刻得多。具体如下：
1. 64 位 MultiXact 成员计数器
长期以来，由于 32 位 MultiXact 成员计数器的限制，PostgreSQL 一直存在一个“不清理就崩溃（Vacuum or die）”的故障隐患。当高并发业务积累了大量的共享行锁（例如 SELECT ... FOR SHARE、外键检查等常见操作）时，很容易耗尽 40 亿（$2^{32}$）的成员空间。一旦耗尽，系统将拒绝接收新事务，而唯一的恢复手段就是在应用下线的情况下，对受影响的数据库进行紧急 VACUUM。
PG19 将该成员计数器扩展到了 64 位。虽然在理论上回绕（Wraparound）数学逻辑依然存在（但如果能用到 $2^{64}$，你该担心的就是其他问题了），但在实际生产中，这种故障模式已不复存在。如果你曾在凌晨 3 点被 multixact member exhaustion（MultiXact 成员耗尽）的告警短信惊醒，这就是你最期盼的特性。如果没有，去问问踩过这个坑的同事吧。
2. 并行自动清理索引工作线程（Parallel Autovacuum Index Workers）
新引入的 autovacuum_max_parallel_workers 参数允许自动清理（Autovacuum）进程像如今的手动 VACUUM (PARALLEL n) 一样，并行处理单张表上的多个索引。在大多数情况下这是一个显而易见的巨大提升，特别是对于那些“列宽且索引多”、以往单线程索引清理速度极慢的大表。
不过，运维时需要格外注意它与 maintenance_work_mem 的相互影响。每个并行工作线程都会占用独立的内存分片。在极端高负载下，一个繁忙的 Autovacuum 进程现在可能会消耗：
$$\text{autovacuum_max_workers} \times \text{autovacuum_max_parallel_workers} \times \text{maintenance_work_mem}$$
的内存。默认配置下问题不大，但如果你的系统经过深度调优、将 maintenance_work_mem 调大到了 4 GB，并且配置了十几个自动清理工作线程，那么在提交升级工单之前，最好重新算一算这笔内存账。
3. 时序表语法：FOR PORTION OF
大家期待已久的 UPDATE ... FOR PORTION OF (period) 及其配套的 DELETE 子句终于落地。该特性允许你仅修改时序表（Temporal table）中某一行在特定时间段（Sub-range）内的数据，PostgreSQL 会自动拆分该行，以保留两侧未被触及的时间段数据。
该功能的底层语义设计得非常严密。但它的运维隐患主要集中在触发器（Trigger）和外键（FK）的交互上：一个 FOR PORTION OF 的更新操作，可能会触发针对某些行的行级触发器——而这些行在语句刚开始执行时甚至根本不存在，因为它们是语句在执行过程中被自动拆分并创建出来的。时序表上的级联外键行为现在比一年前变得复杂、有趣得多。在将时序逻辑推向生产环境之前，务必进行充分测试。该特性的底层规范很完善，但目前应用侧的生态系统还没完全准备好。
4. 默认关闭 JIT（jit = off）
在 PG19 中，jit（即时编译）的默认值改为了 off。这是一个看似悄无声息、实则动静极大的调整。
JIT 自 PG12 开始被默认开启，相当一部分分析型业务（OLAP）一直在默默依赖它，为长周期运行的查询提供执行计划时的代码生成（Plan-time codegen）。但如果你运行的是联机事务处理（OLTP）业务，你几乎从未从 JIT 中受益，反而一直在为每一个超过成本阈值的查询默默支付执行计划的编译开销。因此，这个新的默认值是完全正确的。
如果你运行的是分析型业务（OLAP）——而且出乎意料的是，很多运行 PostgreSQL 的人其实在跑分析型业务自己却没意识到——在升级到 PG19 之前，你需要在 postgresql.conf 中明确设置 jit = on，进行基准测试后再做决定。你绝对不希望在升级完成的那一刻，才猛然发现原本一个 6 分钟的报表现在要跑 19 分钟。
Beta 1 版本的发布，正是开始在真实业务场景中压测这些特性的最佳时机。上面这四个变化，改变的是数据库在生产环境中的实际“体感”和运维策略，而不仅仅是写在宣讲 PPT 上的功能点。
原文地址：https://thebuild.com/blog/2026/05/18/postgresql-19-beta-the-four-features-youll-actually-feel/
