PostgreSQL为何不支持并行DML？并行DML的安全使用条件有哪些

官方默认禁用并行DML的核心原因 #

PostgreSQL的并行查询框架最初仅面向只读场景设计，DML操作涉及事务原子性、WAL日志顺序、锁管理等核心逻辑的强约束，原生禁用并行DML主要基于三个层面的考量：

• 事务一致性保障难度大：同一个查询的多个并行worker进程共享事务上下文，DML操作需要写WAL日志、修改共享缓冲区、维护元组可见性标识，并行执行容易出现WAL写入乱序、缓冲区修改冲突，最终导致数据页损坏或事务回滚不完整。
• 锁冲突与死锁风险高：即便是操作不同分区，多个worker获取意向锁、元组锁、索引页锁的顺序无法被严格控制，锁冲突概率远高于单进程执行，稍不注意就会出现循环等待。
• 历史架构兼容成本高：现有执行器、存储引擎层的核心逻辑没有做并行写入的适配，强行支持并行DML需要修改大量底层代码，且会引入极多难以复现的稳定性问题。

并行DML是否会引发死锁 #

答案是肯定的，且死锁出现的概率远高于普通多事务并发DML场景。
最典型的场景是多个worker操作同一张表的多个分区：worker1先获取分区A的写入锁，再申请分区B的锁；worker2先获取分区B的写入锁，再申请分区A的锁，就会直接触发死锁。就算是操作无分区的普通表，并行插入时更新B树索引的页锁也可能出现循环等待的死锁问题。

安全使用并行DML的前置条件 #

PostgreSQL 11之后版本已经逐步支持有限场景的并行DML（比如INSERT ... SELECT），默认处于关闭状态，需要同时满足所有以下条件才可以安全开启：

• 目标表为分区表，且业务逻辑可以保证每个并行worker仅操作独立的单个分区，不存在跨分区写入
• 写入操作无顺序要求：比如批量插入无唯一约束、无外键约束的时序类、日志类数据，不需要保证插入顺序和SELECT结果集的顺序一致
• 目标表上无触发器、无生成列、无需要级联操作的外键关联
• 提前调整相关配置参数：设置max_parallel_workers_per_gather大于1，PostgreSQL 16及以上版本需要同步开启parallel_insert_mode/parallel_update_mode/parallel_delete_mode对应参数
• 写入时段无其他并发业务操作目标表，或者仅操作当前会话独占的临时表

你场景中提到的函数内调用多组SPI执行DML的逻辑，本质是单进程顺序执行多个独立的SPI调用，不属于数据库原生并行DML范畴，只要你多个SPI操作的锁获取顺序没有逻辑错误，自然可以稳定运行，和我们上面讨论的数据库层面并行DML不是同一类实现。

内容的提问来源于stack exchange，提问作者Bobi.Liu