pg_repack处理13TB大表时CREATE INDEX长期IDLE问题咨询

结论：该现象不正常 #

无流量的测试环境中，pg_repack的索引创建阶段应持续处于ACTIVE状态，且pg_stat_progress_create_index表能实时查询到索引创建进度。当前出现CREATE INDEX长期IDLE、锁事务Idle in transaction且无进度数据的情况，属于异常状态，需介入处理。

可能的原因 #

1. pg_repack版本兼容性问题：1.4.7版本发布于2020年，与2021年推出的PG12.5存在适配bug，导致索引创建阶段流程挂起
2. Aurora底层资源瓶颈：存储IOPS耗尽、CPU/内存不足，导致索引创建进程被系统强制挂起
3. 遗留资源干扰：pg_repack中途异常后，未清理的临时表、锁资源阻塞了后续执行流程
4. 内存参数配置不足：默认的maintenance_work_mem等参数过小，无法支撑9TB级索引的创建需求

处理步骤 #

一、紧急终止异常进程并清理遗留资源 #

1. 定位并终止所有pg_repack相关异常进程：

   SELECT pg_terminate_backend(pid)
   FROM pg_stat_activity
   WHERE query LIKE '%pg_repack%'
      OR query LIKE '%CREATE INDEX%repack%'
      OR query LIKE '%LOCK TABLE public.table_name%';
   

2. 清理pg_repack生成的临时对象：

   DROP TABLE IF EXISTS repack.table_1234;
   DROP INDEX IF EXISTS repack.*;
   

二、优化配置后重新执行pg_repack #

针对13TB级超大表，调整以下配置提升执行效率：

1. 临时调整内存参数（测试环境无流量，可最大化资源利用）：

   -- 根据实例内存调整，例如128GB内存实例设置64GB
   ALTER SYSTEM SET maintenance_work_mem = '64GB';
   ALTER SYSTEM SET work_mem = '2GB';
   -- 会话级临时生效，无需重启实例
   SET maintenance_work_mem = '64GB';
   SET work_mem = '2GB';
   

2. 启用并行索引创建：
   执行pg_repack时添加--parallel参数，根据CPU核心数设置并行度（例如8核实例设置为4）：

   pg_repack -d your_db_name -t public.table_name --parallel 4
   

3. 临时关闭autovacuum：
   避免autovacuum干扰超大表的repack过程：

   ALTER TABLE public.table_name SET (autovacuum_enabled = false);
   

三、排查Aurora特定问题 #

1. 查看CloudWatch指标：重点监控CPUUtilization、ReadIOPS、WriteIOPS、DiskQueueDepth，确认是否存在资源瓶颈
2. 导出并分析PostgreSQL日志：搜索pg_repack、CREATE INDEX相关的错误信息，排查是否有IO超时、锁等待等异常
3. 检查Aurora参数组：确保max_worker_processes大于并行索引设置的数值，避免并行进程不足

四、版本兼容性优化 #

pg_repack 1.4.7与PG12.5存在已知兼容性bug，建议升级至pg_repack 1.4.10及以上版本（适配PG12的最新稳定版），修复老版本中的流程挂起、锁处理等问题

内容的提问来源于stack exchange，提问作者P_Ar