PostgreSQL 过程里 DETACH PARTITION CONCURRENTLY 报事务块错误

分区维护过程在循环中执行并发分离，数据库报：

ALTER TABLE ... DETACH CONCURRENTLY cannot run inside a transaction block

错误上下文指向 PL/pgSQL 过程中的 EXECUTE。即使客户端单独调用 CALL，或者过程自己已经执行过 COMMIT，并发 DETACH 仍不能在该过程内运行。

PostgreSQL 18 要求这项操作由客户端作为顶层语句执行，并且处于事务块之外。过程内的动态 SQL 不会因前一条 COMMIT 变成客户端顶层语句。这里处理的是声明式分区表的 DETACH PARTITION CONCURRENTLY，不是普通 DETACH，也不是所有过程都不支持事务控制。

检查 SQL 实际在哪里执行

先看报错上下文：如果仍写着某个 PL/pgSQL 过程及其 EXECUTE 行号，就还在服务端过程里。把内层 SQL 加一层 BEGIN，或在循环中提前提交，不会消除顶层限制；异常处理块还可能引入子事务。

如果已经移到客户端，再检查驱动、迁移工具或管理界面是否自动开启事务。顶层和事务块之外是两项要求；只满足其中一项仍可能失败。不要为了让这一条维护命令执行，就直接提交一个包含其他业务改动的连接。

并发分离内部使用两个事务：先标记分区正在分离、等待使用父表的已有事务，再完成分离。它因此需要自己控制事务边界，不能把它包成与其他维护动作共同回滚的一次事务。

由客户端单独编排分离操作

保留现有分区与维护配置，安排备份和维护窗口。客户端先取得并核对待处理的分区清单，再在事务块外逐条发送实际维护语句，例如：

ALTER TABLE public.events
    DETACH PARTITION public.events_202601 CONCURRENTLY;

父表和子分区名称都是示例，必须确认该子表仍属于对应父表、保留策略允许分离，且执行角色拥有所需权限。分离会使子表成为独立表，之后通过父表查询将不再包含它；这不是删除子表数据，但仍会改变业务查询和写入路由。

编排工具应记录每个分区的结果，遇到错误先读取当前状态，再决定继续还是重试。名称来自查询结果时，也应使用驱动的标识符引用接口，不把未经验证的字符串拼接成 SQL。

父表有默认分区时，PostgreSQL 18 不允许并发 DETACH。不要为绕过限制直接删除默认分区。需要保留这种结构时，另行评估普通 DETACH 的锁与维护窗口；只有业务需要改变分区设计，才制定相应迁移。

中断后先检查是否已经进入分离状态

并发操作仍会等待事务并取得锁，不能把它理解为“无锁”或“立即完成”。取消、超时或客户端断开之后，不宜直接当作从未执行过。

在同一数据库中可以只读查看父子关系：

SELECT inhrelid::regclass AS partition_name,
       inhdetachpending
FROM pg_inherits
WHERE inhparent = to_regclass('public.events');

inhdetachpending 为真表示该分区正在分离。PostgreSQL 提供 DETACH PARTITION ... FINALIZE 完成先前中断的并发分离；是否使用它，需先核对本次操作和实际状态，不能把 FINALIZE 当作自动回滚或修复所有分区错误的命令。每个父表同时最多有一个待完成分离的分区。

成功后核对目标分区已从父表移除、独立表及数据仍存在，并检查父表查询、写入和保留任务是否符合预期。需要回退分离时，重新挂载分区要重新满足范围、数据和依赖条件，不是简单重跑原过程。

若维护失败发生在创建新分区、错误指向默认分区中的未来数据，则应检查 pg_partman 的默认分区数据与维护范围，不要把那类约束冲突归到过程事务边界。