Our test suite opens and closes many in memory duckdb databases.
Since upgrading to duckdb 1.3.0 we sometimes have a deadlock situation where threads are blocked.
We believe this is because DuckdDBConnection#close calls
connRefLock.lock()resultRefLock.lock() - via DuckDBPreparedStatement.close & DuckDBResultSet.close()
Whereas DuckDBResultSet#next() calls fetchChunk(), which then calls
resultRefLock.lock()connRefLock.lock()
If the timing is wrong one thread could lock connRefLock and wait on resultRefLock while another locks resultRefLock and waits on connRefLock
I think the fix would be to swap the ordering of locks in fetchChunk
Our test suite opens and closes many in memory duckdb databases.
Since upgrading to duckdb 1.3.0 we sometimes have a deadlock situation where threads are blocked.
We believe this is because DuckdDBConnection#close calls
connRefLock.lock()resultRefLock.lock()- via DuckDBPreparedStatement.close & DuckDBResultSet.close()Whereas DuckDBResultSet#next() calls fetchChunk(), which then calls
resultRefLock.lock()connRefLock.lock()If the timing is wrong one thread could lock connRefLock and wait on resultRefLock while another locks resultRefLock and waits on connRefLock
I think the fix would be to swap the ordering of locks in fetchChunk