PostgreSQL 19 的 REPACK 怎么用：在线重建表，但有一个坑文档写得很轻

PostgreSQL 19 已到 RC1，正式版计划 11 月 19 日。这个版本最受 DBA 关注的不是新语法，是一条内置命令：REPACK。

它解决的老问题

大批量 DELETE 之后，PostgreSQL 不会把空间还给操作系统，只是把页标记为可复用，磁盘文件大小不变。经典解法是 VACUUM FULL，但它要排他锁，生产库上基本不能用。另一种是第三方扩展 pg_repack，能在线做，但要单独安装和维护。

REPACK 把这两种能力收进内核，统一了 VACUUM FULL 与 CLUSTER 的功能，并加了 CONCURRENTLY 选项：重建期间正常读写不受影响，期间产生的变更会被捕获并回放，只在最后切换文件时短暂加排他锁。

基本用法

REPACK my_table 做普通重建；REPACK (CONCURRENTLY) my_table 在线重建；REPACK (CONCURRENTLY) my_table USING INDEX 按指定索引聚簇。

必须知道的限制

文档里有一句警告很容易被忽略：REPACK CONCURRENTLY 不是 MVCC 安全的。提交之后，持有更早快照的并发事务可能看到这张表是空的。这意味着长事务、逻辑复制槽、长跑的报表现场，都可能撞上。

另外两个前提：wal_level 至少要 replica；分区表会逐分区处理，但无法并发。

上手建议

先在一张百万级小表上跑一遍，观察锁等待与 WAL 生成量。在线重建会产生大量 WAL，归档空间和从库延迟都要提前留余量。

升级节奏

RC1 适合在非生产环境验证，RC2 定在 11 月 12 日，GA 是 11 月 19 日。关键业务建议等到 19.1 小版本再上。

本文由奇幻维度内容助手整理发布，欢迎在评论区交流你的看法。

不是 MVCC 安全这条提醒很关键，长事务和逻辑复制槽场景都容易踩。在线重建的 WAL 生成量也别低估，从库延迟要提前留余量。

文档写得很轻的那个坑，大概是 REPACK 期间的写放大和锁等待，以及和逻辑复制槽的配合。我们线上做类似操作会先确认复制槽没有滞后，否则重写期间的 WAL 会把从库拖垮。另外并发模式和带索引表组合限制不少，动手前先在影子库跑一遍。