depesz 实测 REPACK CONCURRENTLY 的锁开销与耗时 RSS

PostgreSQL 19 给 REPACK 加了 CONCURRENTLY 选项：大部分时间只持较弱的共享更新排他锁，靠复制槽做逻辑解码追上并发改动，只在最后交换文件节点时短暂升为排他锁。depesz 在一张删掉 80% 行、19GB、两亿行的表上实测，66 秒压到 4.1GB，其间插入延迟从 1.5 毫秒升到平均 5.5 毫秒，峰值约 63 毫秒。已知限制是复制槽稀缺、全库同时只能跑一个 REPACK，末尾升锁还可能死锁。

发布于 2026-09-10T10:59:39.236302Z · Hubert 'depesz' Lubaczewski · depesz.com

PG19 REPACK 实测

PostgreSQL 19 给 REPACK 加了 CONCURRENTLY 选项：大部分时间只持较弱的共享更新排他锁，靠复制槽做逻辑解码追上并发改动，只在最后交换文件节点时短暂升为排他锁。depesz 在一张删掉 80% 行、19GB、两亿行的表上实测，66 秒压到 4.1GB，其间插入延迟从 1.5 毫秒升到平均 5.5 毫秒，峰值约 63 毫秒。已知限制是复制槽稀缺、全库同时只能跑一个 REPACK，末尾升锁还可能死锁。

PostgreSQL 19 给 REPACK 加了 CONCURRENTLY 选项：大部分时间只持较弱的共享更新排他锁，靠复制槽做逻辑解码追上并发改动，只在最后交换文件节点时短暂升为排他锁。depesz 在一张删掉 80% 行、19GB、两亿行的表上实测，66 秒压到 4.1GB，其间插入延迟从 1.5 毫秒升到平均 5.5 毫秒，峰值约 63 毫秒。已知限制是复制槽稀缺、全库同时只能跑一个 REPACK，末尾升锁还可能死锁。

原始来源 ↗

来源记录

• center.info_item · 2bd61253290f6494 · 2026-10-03T04:08:35.169032Z
• pgweb.info_item · 2bd61253290f6494 · 2026-10-03T04:08:55.967155Z