PostgreSQL无法删除表问题：无更新场景下DROP TABLE挂起

• SELECT会持有表级共享锁导致DROP阻塞
  主流关系型数据库（如MySQL InnoDB、PostgreSQL）中，执行SELECT时会对目标表加共享锁（S锁），只要对应的事务未结束，锁就会持续持有。哪怕客户端已经切换到WORLD2，若之前针对WORLD1的SELECT会话未完成（比如长连接里的事务没提交、查询未执行完毕），锁就不会释放，而DROP TABLE需要获取排他锁（X锁），会因锁冲突一直挂起。

• 锁残留的核心原因
  并非客户端切换到WORLD2就会自动释放旧锁——如果客户端用的是长连接，且之前访问WORLD1的事务未终止（比如关闭了自动提交却没手动COMMIT），锁会一直绑定在该会话上，直到会话结束或事务提交。

• 无需全杀客户端的解决方法

  • 精准终止持锁会话：定位到正在持有WORLD1锁的连接单独终止即可。例如MySQL用SHOW PROCESSLIST找到访问WORLD1的进程ID，执行KILL [PID]；PostgreSQL用SELECT pid FROM pg_locks WHERE relation = 'world1'::regclass获取进程ID，再执行SELECT pg_terminate_backend(pid)。
  • 强制自动提交：确保客户端的SELECT处于自动提交模式（多数数据库默认开启），单个查询执行完成后立即释放锁，避免长期持有。
  • 改用原生临时表：如果业务适配，使用数据库原生临时表（如CREATE TEMPORARY TABLE），临时表仅对当前连接可见，连接关闭后自动销毁，不会出现跨连接的锁阻塞问题。
  • 延迟删除策略：先将WORLD1标记为“废弃状态”，通过查找表彻底屏蔽它，等待所有访问过WORLD1的旧会话因超时或主动关闭自然释放锁后，再执行DROP TABLE。

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