PostgreSQL如何不等待持锁事务结束直接删除被锁定行

PostgreSQL 行级排他锁的互斥规则是MVCC一致性保障的底层逻辑，没有任何原生方式可以在不等待持锁事务结束的前提下，直接修改/删除被FOR UPDATE锁定的数据行。任何针对锁定行的写操作默认都会进入等待队列，直到持锁事务提交或回滚释放锁。

你使用的SELECT ... FOR UPDATE SKIP LOCKED语法，SKIP LOCKED的生效范围仅限加锁查询本身：它只会让后续同样执行FOR UPDATE加锁查询的事务跳过已经被锁定的行，不会对DELETE/UPDATE这类写操作生效。写操作默认不会跳过锁，碰到被其他事务锁定的行就会阻塞等待，这就是你第二个事务挂起的根本原因。

你可以根据业务场景选择以下方案，避免删除操作无限挂起：

• 方案1：给DELETE增加SKIP LOCKED逻辑，实现无等待删除
  通过CTE先尝试对目标行加锁，加锁成功才执行删除，加锁失败直接跳过，全程不会阻塞：

  WITH target AS (
      SELECT id FROM myTable WHERE id = 1 FOR UPDATE SKIP LOCKED
  )
  DELETE FROM myTable WHERE id IN (SELECT id FROM target);
  

  该语句执行后如果返回影响行数为0，说明目标行正被其他事务锁定，你可以根据业务需求选择重试删除或者走其他分支逻辑。
• 方案2：设置短锁超时，快速失败避免无限等待
  执行删除前设置语句级锁超时，等待超过阈值直接抛出错误，不会挂起连接：

  -- 仅对当前事务内的语句生效，锁等待超过100ms直接报错
  SET LOCAL lock_timeout = '100ms';
  DELETE FROM myTable WHERE id = 1;
  

  业务代码捕获到锁等待超时的报错后，可以根据业务逻辑做重试、告警等处理，不会出现连接长期占用的问题。
• 方案3：调整业务流程用软删除适配
  如果你的删除操作是为了作废待处理的任务，可以新增软删除标记字段（比如is_cancelled布尔值），作废操作直接更新该字段标记；而原有抢任务的SELECT FOR UPDATE语句在拿到锁之后，先二次校验字段状态，如果发现已经被标记作废就直接回滚跳过处理即可。注意该方案下更新软删除标记的语句同样可以搭配上述SKIP LOCKED或者短锁超时逻辑，避免阻塞。

严禁通过修改系统参数、篡改系统表、使用未公开的hack语法绕过行锁校验，这类操作会直接破坏数据库的ACID一致性，极大概率引发脏写、数据错乱、事务崩溃等问题，生产环境禁止使用。

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