psql 合并删库和建库命令时报事务块错误
psql 把同一个 -c 中的多条 SQL 作为一次请求执行，删库和建库会触发事务块限制。拆成独立 -c，核对维护库和外层事务，并处理删库成功后建库失败的恢复风险。
把删除测试库和重新建库写进同一个 psql -c 参数，可能直接得到：
ERROR: DROP DATABASE cannot run inside a transaction block
例如，问题出在这样的参数组合：-c 'DROP DATABASE app_reset_demo; CREATE DATABASE app_reset_demo;'。不要拿真实数据库试这条语句；DROP DATABASE 会删除整个数据库，本文只讨论明确允许重置的测试库。
即使 SQL 里没有写 BEGIN，一个 -c 中的多条 SQL 仍会作为一个请求发送给服务器，并在同一个事务中执行。DROP DATABASE 和 CREATE DATABASE 都不能在事务块内执行，所以把两条命令用分号接起来，会触发这项限制。若前面放的是建库命令，报错也可能指向 CREATE DATABASE。
以下以 PostgreSQL 的 psql 命令行客户端为准，shell 示例适用于 Linux、macOS 的 Bash 或 zsh。GUI、迁移框架和应用驱动有各自的事务控制，不能仅把这些 psql 参数复制过去。示例按 PostgreSQL 18 的 psql 参数行为核对；使用旧客户端时，应先检查 psql --help 是否支持所用选项。
一个 shell 命令可以包含多个独立请求
需要连续执行时，可以重复使用 -c，让每条 SQL 单独发送。执行前先核对目标连接：
psql -X -h 127.0.0.1 -p 5432 -U your_db_admin -d postgres \
-c '\conninfo'
127.0.0.1、5432、your_db_admin 都是示例，应替换成已确认的测试实例及管理账号。这里连接的是维护库 postgres，而不是准备删除的 app_reset_demo。若当前实例没有可用的 postgres 库，也可以选择另一个允许连接、且不在此次删除范围内的数据库。
核对连接信息中的数据库、主机、端口和用户。不要因为电脑上只有一个终端，就假定它必然连接本机测试库；SSH 隧道、容器端口映射和已有连接配置都可能把请求送到其他实例。密码使用交互提示或既有安全凭据配置，不写进命令行示例。
如果只是想得到一个新的空库，更稳妥的办法是使用未占用的新名字，保留原数据库：
psql -X -h 127.0.0.1 -p 5432 -U your_db_admin -d postgres \
-v ON_ERROR_STOP=on \
-c 'CREATE DATABASE app_reset_demo_new;'
新库默认复制 template1，所有者默认是执行建库的角色。应用若要求特定所有者、编码或排序规则，需要按原部署约定创建；默认建库不等于完整复制原数据库的配置。使用新名字时，还要显式修改测试应用的连接目标。
确实要重置原测试库时
先停用会连接这个测试库的应用和任务，保存需要保留的数据、数据库配置与恢复材料，并确认备份能够恢复。pg_dump 可备份单个数据库，但不保存集群级角色等全局对象；仅有一份 dump 文件不代表所有恢复条件齐全。
确认 app_reset_demo 就是允许丢弃的测试库，且当前连接和其他会话都没有占用它之后，再使用拆开的命令：
psql -X -h 127.0.0.1 -p 5432 -U your_db_admin -d postgres \
-v ON_ERROR_STOP=on \
-c 'DROP DATABASE app_reset_demo;' \
-c 'CREATE DATABASE app_reset_demo;'
这仍是一次 psql 调用，但两个 -c 分别发送请求。末尾的 SQL 分号可以保留；这里的区别在于它们属于两个参数，各自发送一次请求。
-X 跳过系统和用户的 psql 启动文件，避免本地配置暗中改变会话。ON_ERROR_STOP=on 让客户端在首条错误处停止：删除失败后，不再继续尝试建库。它不授予额外权限，也不会撤销此前已完成的操作。
执行删除需要相应的数据库所有者权限；创建数据库则需要超级用户或 CREATEDB 权限。两种权限不能混为一谈。没有必要为了这条命令普遍提高应用账号权限，应使用已有、经过授权的维护账号。
如果报错变成“当前正连接目标数据库”，检查 -d；如果提示其他用户仍在连接，检查测试应用、连接池和后台任务是否真的停止。此时已经进入另一类问题，应按新的错误处理，也不要直接加 FORCE 踢掉所有连接。
拆开后仍报事务块错误
查看最终执行的命令，尤其是包装脚本有没有加入 -1 或 --single-transaction。这个选项会在全部 -c、-f 操作外包一层事务，因此即使写了两个 -c，删库、建库仍然不能执行。
对于本次专门的数据库重置调用，应去掉这个选项。不要把它当成通用修复，顺手删除其他数据导入任务的事务保护；普通表数据导入可能正需要失败后整批回滚。
同样，脚本若先发送 BEGIN，再发送删库或建库命令，也会遇到限制。拆参数不会结束已经存在的事务。应把数据库创建、删除放在独立的维护步骤中，与需要事务保护的表结构和数据操作分开安排。
psql 默认的自动提交也不会把同一个 -c 字符串切成多个请求，所以单纯添加 -v AUTOCOMMIT=on 不能修复最初的写法。分号分开的是 SQL 语句，不一定是客户端发送请求的边界。
建库失败不能回滚已完成的删库
两个请求分开后，删除可能已经成功，而建库因权限、磁盘或其他条件失败。此时不存在“把两条一起回滚”的保证，ON_ERROR_STOP 也不能把已删除的数据库找回来。
失败后保留输出和退出状态，先确认目标库是否存在，再决定补做建库还是启动恢复。不要把整条重置命令当成可随意重试的操作：如果另一人已经恢复了库，再次重跑会把恢复后的内容重新删掉。
两步都成功时，再单独连接重建的测试库验证：
psql -X -h 127.0.0.1 -p 5432 -U your_db_admin -d app_reset_demo \
-v ON_ERROR_STOP=on \
-c '\conninfo' \
-c 'SELECT current_database();'
连接目标和查询结果都应是 app_reset_demo。然后按项目原有流程导入测试结构或初始化数据，检查应用所用角色的权限及测试任务是否正常。看到 CREATE DATABASE 成功，只能证明库已创建，不能证明应用所需的表和数据已经回来。
需要恢复旧内容时，按已经验证的备份恢复流程处理；重新创建同名库只会创建一个新库。若使用前面的新名字方案进行测试，可把应用连接配置切回保留的旧库，但测试期间写入新库的数据不会自动同步回去。