PostgreSQL 9.4/12.1遇SQL错误后Cautious Locking锁释放：是Bug还是设计？

设计逻辑说明 #

• PostgreSQL从首个正式版本开始，就以事务原子性的强一致性为核心设计原则：只要事务内任意SQL语句执行抛出错误——不管是拼写错误的语法问题、约束冲突还是运行时异常——整个事务会被立刻标记为**中止（Aborted）**状态。
  处于该状态的事务，会自动释放此前持有的所有锁（包括业务用到的行锁、表锁、应用自定义的咨询锁），且不会响应任何新的SQL请求，直到客户端显式发送ROLLBACK指令回滚整个事务，或通过ROLLBACK TO SAVEPOINT回滚到报错前的某个保存点，事务才能恢复正常运行。
• 这种行为和Oracle、SQL Server的默认机制有本质差异：后两类数据库默认采用语句级错误隔离，单条SQL执行报错时，只会回滚当前这条SQL产生的变更、释放这条SQL单独申请的临时锁，整个事务仍然保持活跃，之前持有的行锁不会受影响——这也是Cautious Locking机制在其他数据库上的默认行为表现。

预编译模式下的异常原因 #

• SQLPrepareW执行时返回“预编译语句已存在”的报错，本质是会话层面的资源没有正确清理：PostgreSQL的服务端预编译语句是和当前会话一一绑定的，如果复用同一个ODBC语句句柄去准备新的SQL内容，没有先解绑句柄上之前绑定的旧预编译语句元数据，就会触发这类冲突报错。
• 碰到“数据库繁忙”的提示，根源是事务被错误标记为Aborted状态后，没有收到客户端的回滚指令，服务端会把该会话发来的所有后续请求全部挂起，等待回滚操作触发，从客户端视角看就像是数据库临时繁忙无法响应。

适配方案 #

要在PostgreSQL上实现原有的Cautious Locking效果，不需要改动数据库核心逻辑，只需要匹配它的事务模型做调整：

• 把“持有行锁的修改事务”和“用户执行即席查询的任务”拆分到独立的数据库会话中，从根源上避免即席查询的SQL错误波及持锁的会话事务。
• 如果必须在同一个会话中执行即席查询，在执行任意即席SQL前先创建保存点（SAVEPOINT sp_before_adhoc;），如果即席SQL执行报错，立刻执行ROLLBACK TO SAVEPOINT sp_before_adhoc;，既可以清除报错状态，也不会回滚整个事务、丢失之前持有的行锁。
• 在PostgreSQL ODBC驱动的配置中调整事务错误处理规则，不要在单条SQL报错时直接中止整个事务，配合驱动的错误拦截逻辑实现上述的保存点回滚操作。

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