pg_repack数据丢失问题分析：并发vacuum与表交换的风险

在PostgreSQL数据库维护工具pg_repack的使用过程中，我们发现了一个可能导致数据静默丢失的严重问题。这个问题涉及pg_repack内部表交换机制与PostgreSQL的vacuum进程并发操作时的交互问题。

问题背景

pg_repack是一个常用的PostgreSQL扩展，它可以在线重组表数据而不阻塞DML操作。其工作原理是创建一个临时表，将原表数据复制到临时表，然后通过表交换操作完成重组。在这个过程中，原表和临时表会短暂地共享相同的物理文件（relfilenode）。

问题复现场景

1. 准备阶段：创建一个测试表并插入三条记录
2. 执行pg_repack操作，在数据复制到临时表后暂停
3. 更新原表中的一条记录，产生死元组
4. 恢复pg_repack操作，应用日志后在表交换前再次暂停
5. 对临时表执行vacuum，收集死元组信息但未实际清理
6. 完成表交换操作，此时原表和临时表共享同一物理文件
7. 对原表执行vacuum，清理死元组
8. 插入新数据，可能被后续恢复的第一次vacuum错误清理

技术原理分析

问题的核心在于pg_repack的表交换过程中，两个逻辑上不同的表（原表和临时表）会短暂地共享相同的物理文件。当两个vacuum进程并发操作这些表时：

1. 第一个vacuum进程扫描临时表，标记死元组但尚未清理
2. 表交换后，第二个vacuum进程扫描原表（现在与临时表共享文件），实际清理死元组
3. 新插入的数据可能被第一个vacuum进程误认为死元组而清理

这种竞态条件会导致数据静默丢失，且难以追踪和恢复。

解决方案

修复方案相对简单直接：在pg_repack执行表交换操作前，需要同时获取原表和临时表的AccessExclusiveLock。这样可以确保：

1. 在交换过程中不会有其他会话访问这些表
2. 防止vacuum进程并发操作同一物理文件
3. 保证表交换操作的原子性和安全性

经验教训

这个案例给我们几个重要的启示：

1. 在PostgreSQL扩展开发中，需要特别注意锁粒度和锁获取顺序
2. 涉及物理文件交换的操作需要格外谨慎处理并发场景
3. 静默数据丢失是最危险的问题类型，需要设计时优先考虑
4. 复杂操作应该分解为更小的原子步骤，并确保每个步骤的隔离性

最佳实践建议

对于使用pg_repack的用户，建议：

1. 及时更新到修复此问题的版本
2. 在低峰期执行repack操作
3. 考虑增加维护窗口，在repack前后执行数据校验
4. 监控repack过程中的锁等待情况

对于开发者，建议：

1. 在涉及表交换的设计中充分考虑并发场景
2. 增加适当的锁机制确保操作安全
3. 考虑添加操作日志以便问题追踪
4. 进行充分的并发测试覆盖边界条件