pg_repack是PostgreSQL生态里处理表膨胀最常用的工具之一，它能够在基本不中断业务写入的前提下完成表的重建，回收磁盘空间并重建索引。不过很多使用者在生产环境跑pg_repack时踩过坑：工具卡住不动、业务查询突然被阻塞，甚至出现连接堆积。这些现象几乎都和锁有关。pg_repack并不是全程无锁，它在若干关键节点需要短暂获取排他锁（AccessExclusiveLock），理解这些时刻对安全使用至关重要。
pg_repack的基本工作流程与锁的分布
要弄清楚什么时候会拿排他锁，先要看懂pg_repack的整体流程。它的大致步骤是：先在目标表上加上ShareUpdateExclusiveLock锁并检查表的继承关系和主键，然后创建一张与原表结构相同的中间表（通常以repack.table_xxx命名），接着在原表上创建触发器，把原表上发生的INSERT、UPDATE、DELETE同步记录到日志表里。之后工具开始全量拷贝原表数据到中间表，拷贝完成后回放日志表中的增量变更，最后在两个表数据完全一致时，用一个短暂的事务交换两张表的名字并重建索引、恢复约束和权限。
在整个流程里，锁的级别是在不断变化的。准备阶段和拷贝数据阶段主要持有ShareUpdateExclusiveLock，这个级别只阻塞自动ANALYZE、VACUUM和DDL，普通的SELECT和DML完全不受影响，所以业务基本无感知。真正需要紧张的是两个点：一是创建同步触发器的瞬间，二是最后交换表名的瞬间。这两个时刻都必须拿到AccessExclusiveLock，也就是最高级别的锁，它和所有其他锁都冲突。
这里有一个非常容易被忽视的连锁反应：PostgreSQL的锁队列是严格排队的。一旦pg_repack在队列里申请了排他锁，后续所有针对这张表的新查询都会排在它后面等待。此时哪怕有一个客户端开着事务忘了提交，或者一条报表SQL跑了半小时没结束，整个队列就会被卡死，业务表的读写全部挂起。很多人以为pg_repack本身很温和，结果造成业务故障，根源就在这里。
两个必须获取排他锁的关键时刻
第一个时刻：安装同步触发器
pg_repack在开始拷贝数据之前，需要在原表上创建一个行级触发器来捕获增量变更。执行CREATE TRIGGER时，事务必须持有ShareRowExclusiveLock，同时还需要短暂的AccessExclusiveLock来完成系统目录的更新。这个锁的持有时间非常短，通常只有几毫秒，但前提是能够立刻拿到。如果此刻表上正好有正在执行的查询，repack就必须等待，等待期间它已经在锁队列里排了排他锁，后续新来的业务查询全部被压在后面，形成明显的阻塞峰值。
第二个时刻：交换表名（最终切换）
这是整个流程中最关键、风险最高的排他锁时刻。数据全量拷贝和增量回放完成后，pg_repack要在一个事务里完成几件事：对原表加AccessExclusiveLock，把日志表里最后一批变更回放完毕，然后通过重命名系统目录的方式交换原表和中间表的名字，最后在新的表（也就是中间表转正的那张）上重建索引。其中重命名操作本身极快，毫秒级完成，但如果回放的日志量大，事务持锁时间就会被拉长。更麻烦的是，如果原表上的写入很密集，日志不断产生，repack可能反复尝试始终追不上增量，一直拿不到一致性窗口，这个阶段反复申请排他锁失败，阻塞就会反复出现。
可以通过下面的查询实时观察repack会话正在等什么锁：
-- 查看当前被阻塞的会话及等待的锁类型
SELECT pid, wait_event_type, wait_event, state,
now() - query_start AS duration,
left(query, 80) AS query
FROM pg_stat_activity
WHERE datname = current_database()
ORDER BY duration DESC;
-- 查看锁等待链，找出阻塞源头
SELECT blocked.pid AS blocked_pid,
blocking.pid AS blocking_pid,
blocked.query AS blocked_query,
blocking.query AS blocking_query
FROM pg_stat_activity blocked
JOIN pg_stat_activity blocking
ON blocking.pid = ANY(pg_blocking_pids(blocked.pid));
定位到阻塞源头后，如果确认是无关紧要的慢查询，可以考虑用pg_terminate_backend把它结束掉，让repack尽快拿到锁完成切换，避免锁队列继续堆积。
如何把排他锁等待时间降到最低
设置合理的lock_timeout
pg_repack支持通过命令行参数控制锁等待行为，最核心的是--lock-timeout。它的作用是：repack在申请排他锁时，如果在指定时间内拿不到就主动放弃并回滚，释放锁队列，让业务恢复正常。典型用法如下：
# 设置锁超时为10秒，等待失败自动重试 pg_repack -d mydb -t big_table --lock-timeout=10s # 同时限制单次拷贝的时间窗口 pg_repack -d mydb -t big_table \ --lock-timeout=10s \ --wait-timeout=60s \ -j 4
如果不设置这个参数，repack默认会无限等待，在长事务较多的库里这是相当危险的行为。建议生产环境一律显式设置为10秒以内的值，宁可让repack失败重跑，也不要让业务表被无限期排队阻塞。
避开长事务和复制槽积压
排他锁拿不到的最常见原因就是长事务。执行repack之前，务必检查库里是否存在运行时间很久的事务：
-- 找出执行时间超过5分钟的事务
SELECT pid, now() - xact_start AS xact_age,
state, left(query, 60) AS query
FROM pg_stat_activity
WHERE xact_start IS NOT NULL
AND now() - xact_start > interval '5 minutes'
ORDER BY xact_age DESC;
除了用户事务，还要注意备库反馈和逻辑复制槽的影响。如果配置了逻辑复制，且下游消费者停了， xmin或复制槽会阻止旧元组清理，虽然这不直接阻塞锁，但会让repack内部的清理判断变慢。另外，部署了hot_standby反馈的只读节点上的长查询同样可能持有快照，间接拖长repack的等待链。执行前最好和业务方确认窗口，暂停已知的批处理任务和报表查询。
选择合适的时间和参数组合
排他锁的持有时间虽然短，但申请时机很重要。对于写入非常密集的表，建议在业务低峰期执行，并适当加大--wait-timeout-after-rebuild等相关等待参数，给repack更多机会找到一致性切换点。如果表特别大且写入压力无法降低，可以考虑分区方案，逐个对分区执行repack，把每次排他锁的影响范围缩小到单个分区。此外，-j参数可以并行建立索引，加快切换阶段的速度，间接缩短排他锁的间接影响时间。
常见问题与排查思路
实际使用中，如果发现pg_repack长时间没有输出，第一步不要急着杀进程，先看它的等待事件。如果pg_stat_activity里repack会话的wait_event是Lock，就说明它正在排队申请锁，此时应该去找阻塞它的会话。如果repack已经因为lock_timeout失败退出，日志里会有明确的报错信息，比如could not obtain lock，这种情况下处理好长事务后直接重跑即可，repack是幂等性设计，残留的中间表会在下次执行时自动清理，也可以手工删除repack模式下的遗留对象。
还有一个细节值得注意：repack切换表名后，原表会被删除，表上原有的自定义触发器、外键约束需要显式处理。如果表被其他表的外键引用，repack需要额外的锁来重建依赖关系，这种场景下建议使用--only-indexes模式只重建索引，或者提前梳理外键拓扑，从被引用的核心表开始执行。理解了这些排他锁的细节，pg_repack就能真正成为生产环境中安全可靠的表维护利器。
pg_repack排他锁PostgreSQL表膨胀修改时间：2026-09-14 09:14:50