前言
昨晚 PostgreSQL 19 Beta 1 正式发布了。准确说，是 PostgreSQL Global Development Group 在 2026 年 6 月 4 日发布了 PostgreSQL 19 的第一个 Beta 版本，所以 Beta 阶段一些功能细节仍然可能变化。主要特性包括
性能：AIO、外键检查、优化器、排序、COPY、LISTEN/NOTIFY。 维护：autovacuum 并行化、REPACK、在线 checksum、partition split/merge。 可观测性：pg_stat_lock、pg_stat_recovery、更多 stats_reset、EXPLAIN AIO 统计。 复制：逻辑复制 sequence、publication except、按需启用 logical WAL。 SQL 能力：SQL/PGQ、GROUP BY ALL、WAIT FOR LSN、ON CONFLICT DO SELECT。 兼容性变化：JIT 默认关闭、TOAST 默认 lz4、RADIUS 移除、MD5 警告。
AIO
PG18 引入了异步 I/O 子系统，PG19 继续增强这一块。这次 io_method=worker 可以基于新的 io_min_workers、io_max_workers 自动调整 I/O worker 数量，将存储 I/O 这块做得更主动，而不是完全依赖传统同步读写路径。相信引入 AIO 愈发成熟之后，尤其是大表扫描、并行顺序扫描、分析型 SQL、冷热数据混合访问这些场景，会大大受益。
简而言之，PG18 是把 AIO 框架搭起来，PG19 开始把调度、观测、执行路径继续补上。
优化器和执行器
PG19 在优化器和执行器上也有不少改动，比如：
NOT IN、LEFT JOIN 等更多场景可以转换成 anti-join，解决了一个历史老大难问题！ incremental sort 使用范围更广。 eager aggregation 可以更早处理聚合，减少后续处理的行数。 IS DISTINCT FROM / IS NOT DISTINCT FROM 在输入非空时可以简化为普通比较。 sort 里引入 radix sort 相关优化。
LISTEN/NOTIFY 也被照顾了
PG19 改进了 LISTEN / NOTIFY 在多 channel 场景下的可扩展性。以前 NOTIFY 更容易唤醒不必要的 backend，现在会更精准。
这个特性不是人人都用，但如果你真把 PostgreSQL 当轻量消息通知系统用，或者一些业务框架依赖 LISTEN/NOTIFY 做缓存失效、任务通知，这块就值得关注。
LISTEN/NOTIFY 的案例也推荐各位看一下：乱用异步消息 | 数据库CPU被“吃”光了
维护：DBA 会喜欢的东西变多了
维护类特性是最有"DBA 味"的：
autovacuum 支持并行 worker，以前手工 VACUUM 可以用 parallel worker，但 autovacuum 不行。PG19 开始，autovacuum 可以使用 parallel vacuum workers，并且可以通过 autovacuum_max_parallel_workers 以及表级参数 autovacuum_parallel_workers 控制。
PG19 还有一个很有意思的改动：查询表扫描时可以把页面标记为 all-visible。以前 visibility map 主要靠 VACUUM、COPY FREEZE 等路径维护。PG19 让普通查询在合适场景下也能帮后续 vacuum 减负。
REPACK 进入 PostgreSQL：
PG19 新增了 REPACK 命令，并支持 CONCURRENTLY 选项，类似 vacuum full concurrently。这块很容易让人想到 pg_repack 扩展。过去我们想在线重整表、降低膨胀，常常要依赖扩展或复杂操作。PG19 把这类能力往核心里收，是一个很值得关注的方向。
分区表
分区表终于能 split / merge 了
ALTER TABLE ... MERGE PARTITIONS
ALTER TABLE ... SPLIT PARTITIONS
PG19 提供 split / merge，至少让分区结构重组更像一个数据库内建能力，而不是全靠 DBA 手搓脚本。
逻辑复制
逻辑复制终于支持 sequence values 复制，对于逻辑复制来说是个重大里程碑，不再需要一堆手搓脚本。 CREATE PUBLICATION 支持 EXCEPT，也就是说，可以发布数据库里大部分表，但排除其中一部分。这个比一张张列举表方便很多。尤其是库里表很多，只想排除日志表、临时业务表、审计归档表时，这个语法非常顺手。 wal_level=replica 时也能按需启用 logical，PG19 还有一个很重要的变化：逻辑复制可以在 wal_level=replica 时按需启用，配合新的只读参数 effective_wal_level 查看当前实际 WAL 级别。以前为了可能的逻辑复制场景，很多环境会提前把 wal_level 设置成 logical，然后背着额外 WAL 成本跑很久。
可观测性
pg_stat_lock：PG19 新增了 pg_stat_lock 视图，用来报告按锁类型聚合的统计信息。以前我们看锁，主要看 pg_locks、pg_stat_activity、日志里的 log_lock_waits。这些当然有用，但更多是“当前正在发生什么”。pg_stat_lock 更像是补了一层统计视角：一段时间内，哪些锁类型更忙，哪里等待更多。
pg_stat_recovery：PG19 新增 pg_stat_recovery，提供恢复过程更细的状态信息。对主备、归档恢复、PITR、灾备演练来说，这类视图非常有用。以前很多恢复过程只能看日志，或者靠经验判断现在卡在哪一步。现在有视图，就更容易自动化监控和可视化
PG19 给很多统计视图增加了 stats_reset 列。
EXPLAIN ANALYZE 支持 AIO 统计，和 AIO 本身是配套的
SQL 和开发体验
SQL/PGQ 图查询：PG19 引入 SQL/PGQ，支持用 SQL 标准语法做 property graph 查询，很多业务数据天然就是图结构，比如账户关系、设备拓扑、交易路径、权限继承、社交关系。过去在 PostgreSQL 里做这类分析，常常靠递归 CTE、数组、临时表硬拱SQL/PGQ 给了一个更标准的表达方式。 GROUP BY ALL：PG19 支持了把所有非聚合、非窗口输出列都加入 grouping，可以减少一些重复书写。尤其是报表 SQL 里，select 列很多，group by 也要跟着写一遍，确实烦。当然，语法糖也是糖，别因为少写几个字段就忘了 SQL 的分组语义。 INSERT ... ON CONFLICT DO SELECT：这类能力对插入，如果已经存在就返回已有行的场景很方便。 WAIT FOR LSN：新增 WAIT FOR LSN，可以让 session 在备库上等待某个 LSN 已经 replay，再执行读取。比如主库写入后，业务想从只读副本读取，但又怕复制延迟导致读不到刚写的数据。过去这类逻辑要靠应用层判断 LSN、轮询复制状态。PG19 提供了更直接的 SQL 能力。对于读写分离架构是个利好消息。
安全和连接：SNI、密码过期、MD5 警告
服务端支持 SNI 密码过期提醒：PG19 新增 password_expiration_warning_threshold，默认 7 天，用来在密码即将过期前提醒用户。没想到吧，直到 19 才有了此特性 MD5 继续被敲打：PG18 已经标记 MD5 密码认证为 deprecated。PG19 在 MD5 认证成功后，会向客户端发 warning，参数 md5_password_warnings 可以控制。官方在提醒大家：别再赖着 MD5 不走了。能上 SCRAM 的，尽早上。
另外还有 max_locks_per_transaction 默认变成 128，我之前曾说过 fast-path lock
PG18 的核心改造，没有改 fast-path locking 的基本协议，而是改了它的容量和数据结构，不再把这块空间硬塞在 PGPROC 里，而是放到单独分配的共享内存区域；容量变得更大，并且和 max_locks_per_transaction 关联，可调； 在 10 个分区、max_locks_per_transaction=64 的场景下，PG18 相比 PG17，大约有 3x 到 5x 的提升； 在 100 个分区、max_locks_per_transaction=1024 的场景下，大约有 3x 到 8x 的提升。 |
小结
再强调一次：这是 Beta 1，不是 GA。它适合测试，适合验证，适合提前适配，适合给社区报 bug。不适合生产。
最终 GA 前，功能细节、行为、API、甚至个别特性都有可能调整。推荐阅读：https://github.com/nori-shinoda/documents/blob/main/postgresql19_beta1_new_features_en_20260604-1.pdf
