Postgres12长时导入操作子分区引发父表锁阻塞问题排查

直接回答核心疑问 #

子表上的DML锁会自动衍生为父表的AccessShareLock，这是Postgres原生分区的内置强制规则，不需要事务显式访问父表就会触发。

具体机制说明 #

1. 分区锁继承规则：任何事务对分区树中的任意子节点执行DML/查询操作时，不仅会在实际操作的子表上申请对应锁（比如DML会拿RowExclusiveLock），还会自动在所有上层父分区表上申请AccessShareLock，防止事务执行期间父表分区结构被修改。
2. 你查不到父表锁的原因：你之前的锁排查SQL加了where t.relkind = 'r'的过滤条件，但分区父表的relkind是'p'（分区表），不属于普通表'r'，所以父表上的衍生锁被过滤掉了，你才会误以为长导入没有持有父表锁。
   修正后的锁排查SQL：

   select pid, relname, mode, relkind
   from pg_locks l
   join pg_class t on l.relation = t.oid
   where t.relkind in ('r', 'p');
   

3. 锁冲突逻辑：创建子分区的DDL语句需要在父表上申请AccessExclusiveLock来修改分区元数据，而AccessShareLock和AccessExclusiveLock是完全互斥的——只要前者被长导入持有，后者就会一直等待，造成业务阻塞。

非阻塞场景的原因 #

偶尔不出现阻塞的情况基本都是以下几种：

• 长导入任务刚启动，还没有执行任何DML操作到子表，此时还未触发父表的衍生锁申请，Web端的创建分区请求可以先拿到AccessExclusiveLock完成操作。
• 你使用了CREATE TABLE IF NOT EXISTS语法，如果目标子分区已经被导入逻辑提前创建，Web端的语句会直接跳过元数据修改，根本不会申请父表的AccessExclusiveLock。
• 导入是自动提交模式，每一批DML执行完立刻提交，父表上的AccessShareLock只会持有几秒，Web端的请求刚好在锁释放的间隙拿到了锁。

无需调整现有按inventory_id分表的设计，优先选择以下方案：

1. 全量重载场景最优解（完全消除长锁阻塞） #

针对每日全量重载的需求，改用「临时表导入+在线挂载」的流程，全程不碰父表，仅在最后切换时用毫秒级锁：

• 创建和目标子表结构完全一致的独立临时表，不做分区挂载：

  CREATE TABLE inventory_items_#{inventory_id}_new (LIKE inventory_items INCLUDING ALL);
  

• 将全量CSV数据导入这个临时表，过程完全不涉及父表，不会在父表上产生任何锁，Web端新库存创建操作完全不受影响。
• 导入完成后，通过毫秒级元数据操作完成分区切换：

  -- 卸载旧子分区，父表AccessExclusiveLock仅持有几毫秒
  ALTER TABLE inventory_items DETACH PARTITION inventory_items_#{inventory_id};
  -- 挂载新临时表为正式分区，同样仅需毫秒级锁持有时间
  ALTER TABLE inventory_items ATTACH PARTITION inventory_items_#{inventory_id}_new FOR VALUES IN (#{inventory_id});
  

• 删除旧的子分区数据即可。

2. 常规追加导入优化 #

如果只是往现有子分区追加数据，不需要全量重载：

• 拆分长事务为短批次提交（比如每1~10万条提交一次），父表上的AccessShareLock只会在每批导入的几秒内持有，不会长期阻塞父表的DDL。
• 把子分区创建逻辑提前到「Web端创建库存」的流程中，在INSERT INTO inventories的同一个事务里完成子分区创建，提前释放父表的AccessExclusiveLock，避免后续导入时和新分区创建冲突。

注意：不要为了规避锁竞争尝试删除父表的AccessShareLock，否则会出现事务执行期间分区结构被修改、数据路由错误的严重一致性问题。

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