PostgreSQL 19正式版发布：REPACK在线瘦身、异步I/O全量铺开，升级前先看这份避坑清单

2026年10月，PostgreSQL 19正式版（19.0）按计划落地。这是全球最流行的开源数据库一年一度的重磅更新，DBA圈等这一版已经等了整整一年。

这一次的关键词是“减负”。表膨胀有了内置解法，异步I/O从局部试点走向全量覆盖，autovacuum拿到了自己的打分系统。发布前的三个月，社区也做了一件少见的事：砍掉了好几个明星特性。

先说砍掉了什么，比多了什么更重要

Beta阶段曾经宣传的几大特性，最终没能留在19里。

SQL/PGQ属性图查询（CREATE PROPERTY GRAPH和GRAPH_TABLE）在Beta 4被撤回。时间类型的UPDATE/DELETE … FOR PORTION OF语法被撤回。ALTER TABLE的MERGE PARTITIONS和SPLIT PARTITION被撤回。pg_get_role_ddl()等三个DDL导出函数也被移除。更早的Beta 3还撤回了GROUP BY ALL。

原因写在Beta 4的官方公告里：稳定性和可预期的发布节奏优先，这些特性留待后续大版本。

这对开发者的实际影响很具体。如果整个夏天都在关注PG 19的路线图，笔记本里记着“19支持属性图查询”，现在需要划掉这一行。Oracle Database 23ai目前仍然提供SQL/PGQ，PostgreSQL这边至少要再等一个版本。

避免踩坑的办法只有一个：升级前逐条核对官方Release Notes，别照搬6月Beta 1时期的旧文章。

REPACK：表膨胀治理不再需要VACUUM FULL式的停摆

每个PostgreSQL老手都被表膨胀折磨过。高频更新和删除让表和索引越长越肥，查询越来越慢。传统解法是VACUUM FULL，它能回收空间，代价是全程持有ACCESS EXCLUSIVE锁，业务只能干等。

PostgreSQL 19把REPACK做成了内置命令，直接替代VACUUM FULL和CLUSTER的职责（老命令保留兼容）。

REPACK的普通模式同样加排他锁。真正值钱的是REPACK (CONCURRENTLY)：重建表的同时，读写可以继续进行。生产库终于可以在业务时间做空间回收，不用再约凌晨三点的变更窗口。

一条命令的用法：

“`

REPACK orders;

REPACK (CONCURRENTLY) orders;

“`

注意两点。REPACK (CONCURRENTLY)耗时更长、占用更多磁盘（新旧两份表并存）；表上存在无效索引或物化视图时，早期Beta出过崩溃Bug，Beta 4已修复，升级后记得用小表先验证。

异步I/O：从读写数据面走向执行引擎

PG 16引入异步I/O，PG 18用于顺序读，PG 19把它铺得更开。这一版的异步I/O延伸到了WAL写入等更多路径，配合EXPLAIN (ANALYZE, IO)能看到每个执行节点新增的异步I/O与预读统计。

对开发者来说，诊断手段变强了。以前判断预读有没有生效，只能盯着buffer命中率猜。现在跑一遍EXPLAIN (ANALYZE, IO)，每个节点的I/O耗时和预读量直接列出来。

实测建议：拿到19之后，对核心慢查询跑一次EXPLAIN (ANALYZE, IO)，把输出存档。这是后续判断升级收益的基线数据。

autovacuum拿到打分系统，监控视图大换血

autovacuum是PG的自动垃圾回收，但它先处理哪张表，长期以来像黑盒。PG 19新增pg_stat_autovacuum_scores视图，每张表一行，展示autovacuum给它的紧急度打分。哪张表排在哪里，第一次变得可查。

另一张新视图pg_stat_lock统计每种锁类型的累计等待次数和等待时间。锁等待分析不再依赖pg_stat_activity的瞬时快照，可以看累积数据。

这版新增的系统视图还包括pg_stat_recovery（恢复状态统计）和pg_dsm_registry_allocations（动态共享内存分配）。老视图也加了不少字段，pg_stat_progress_vacuum和pg_stat_progress_analyze新增started_by，能看出是谁启动了这次清理。

一个会破坏监控脚本的改动：pg_stat_subscription_stats的sync_error_count字段改名为sync_table_error_count。如果Grafana面板或巡检脚本里引用了这个字段，升级当天就会报错。

升级清单：五件事按顺序做

核对Release Notes，确认没有依赖被撤回的特性（SQL/PGQ、FOR PORTION OF、MERGE/SPLIT PARTITION、GROUP BY ALL）。
全局搜索sync_error_count，把监控和巡检脚本改成sync_table_error_count。
在预发环境用真实数据量验证REPACK (CONCURRENTLY)，评估耗时和磁盘占用。
挑十条核心慢查询跑EXPLAIN (ANALYZE, IO)存档，作为性能基线。
用pg_stat_autovacuum_scores审查全库，autovacuum常年排不上的大表单独治理。

大版本升级仍然采用pg_upgrade或逻辑复制两种路径，停机预算紧张的团队提前演练。

写在最后

PostgreSQL 19是一次务实的版本。REPACK解决的是十年老问题，异步I/O和autovacuum打分是量变积累。被撤回的特性反而体现了这个社区的决策方式：宁可延期，不带着疑问上线。

对正在选型的团队，PostgreSQL依然是那个答案。Supabase、Neon、Amazon Aurora PostgreSQL都会很快跟进19，生态适配只是时间问题。值得做的第一件事很朴素：把测试环境升上去，跑一遍自己的业务负载。