Flyway清理PostgreSQL 11数据库时卡住问题求助

从你提供的日志和线程栈来看，问题出在Flyway执行clean操作时，卡在了等待PostgreSQL的响应（线程栈停在socketRead0，说明Java客户端在等待数据库返回结果），大概率是数据库端存在未释放的锁，导致Flyway无法DROP相关表（包括Flyway的历史表flyway_schema_history）。下面是具体的排查和解决步骤：

1. 先排查数据库端的锁与事务状态 #

登录到PostgreSQL数据库，执行以下SQL查询，定位阻塞源头：

-- 查看等待中的锁
SELECT * FROM pg_locks WHERE NOT granted;

-- 查看长时间处于"idle in transaction"的事务
SELECT pid, query, state, now() - query_start AS duration FROM pg_stat_activity WHERE state = 'idle in transaction';

如果发现有事务长时间未提交/回滚，或者某个进程持有了flyway_schema_history表或其他业务表的排他锁，那就是导致clean阻塞的核心原因——Flyway的clean操作需要DROP表，必须等待这些锁释放。

2. 确保测试中的事务都正确收尾 #

你的测试用@AfterEach执行remigrate，要重点检查测试方法里的事务是否都正确关闭：

• 如果测试用了Spring的@Transactional，确认测试结束后Spring自动回滚了事务（默认是回滚，但如果手动修改了事务属性要注意）。
• 如果是手动开启的JDBC事务，必须在测试方法末尾显式执行commit或rollback，不能让事务挂起。
• 检查是否有异步操作在测试结束后还持有数据库连接，比如异步线程里的事务没处理完，导致连接池里的连接还处于事务中。

3. 调整Flyway remigrate的执行策略 #

频繁在每个测试后执行clean+migrate本身就容易引发锁冲突，建议优化：

• 改为在@BeforeAll执行一次clean+migrate，所有测试共享同一套初始化数据，测试内的修改用事务回滚来清理（而不是整个库clean）。
• 如果必须每个测试后重置，那在执行flyway.clean()前，先强制重置数据库连接池，确保所有活跃连接都被关闭：

  // 假设用的是Hikari连接池
  hikariDataSource.close();
  // 重新初始化连接池后再执行clean
  flyway.clean();
  flyway.migrate();
  

4. 检查版本兼容性与日志增强 #

• 确认Flyway版本和PostgreSQL版本是否兼容，比如旧版Flyway可能对新版PostgreSQL的锁机制支持不好，尝试升级Flyway到对应兼容的版本。
• 在PostgreSQL的postgresql.conf里开启log_lock_waits = on，重启数据库后，就能在日志里看到具体是哪个锁在等待、被哪个进程阻塞，帮助精准定位问题。

5. 临时应急方案（不推荐长期使用） #

如果确实是flyway_schema_history表的锁问题，可以尝试在clean前先手动终止持有锁的进程（用SELECT pg_terminate_backend(pid);），但这只是临时绕过，还是要从根源解决事务未收尾的问题。

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