You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 60d8c75
Browse filesBrowse the repository at this point in the historyBrowse files
fix(connection): make close() safe while a query is running
Closing a connection while another thread was executing a query on it
destroyed the native connection under the running query. Depending on the
query this hung the process, aborted it with heap corruption, or segfaulted
(a write). AsyncConnection.close() hit the same path, since it closes its
connections before shutting down its executor.
Connection now counts calls in flight in every method that reaches the
native connection. close() refuses new calls, interrupts a running query
(repeating the interrupt until the call returns, because an interrupt that
arrives while the query is still compiling is cleared when execution
starts), and waits for in-flight calls to leave the engine before releasing
the native connection. Calls made after close() raise "Connection is
closed." The guard lives in the Python layer, so it covers both backends.
close() called from inside one of the connection's own calls on the same
thread raises instead of waiting for itself. A Python UDF that calls into a
connection while it runs a query (close(), execute() or any other call)
raises too: UDFs run inside the query in flight, so such calls used to wait
for themselves forever, on main as well. A per-thread stack of active calls
and UDFs tells these apart from the connection's own nested calls, and
covers UDFs folded on the calling thread while binding. UDFs are shared by
all connections of a database and the driver cannot tell which query runs
one, so a UDF may not call any connection that has a call in flight;
create_function() documents this. interrupt() also reaches the pybind
connection used as a fallback by the C-API backend, and is a no-op on a
closed connection. The scan-object lookup for LOAD FROM no longer assumes a
fixed call depth and walks up to the first frame outside this module.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
0 commit comments