Commit 45ee912
fix: Close DuckDB cursor to release internal buffers
Root cause: DuckDB cursor objects were never being explicitly closed,
causing internal buffers to accumulate in memory.
The pattern was:
```python
rows = conn.execute(sql).fetchall()
```
This creates a cursor object from `conn.execute(sql)`, fetches all rows,
but never closes the cursor. Even after `fetchall()` and `del rows`,
the cursor object holds references to DuckDB's internal result buffers.
These buffers accumulate across queries, causing steady memory growth
that GC cannot collect (they're managed by DuckDB's C++ layer, not Python).
Solution: Explicitly close cursor after fetching results
```python
cursor = conn.execute(sql)
rows = cursor.fetchall()
# ... process data ...
cursor.close() # Release DuckDB internal buffers
del cursor
```
This ensures DuckDB's C++ result buffers are freed immediately after
the query data is extracted, rather than accumulating until the
connection is closed/reset.
Expected impact: Memory should stabilize immediately. Each query will
fully clean up after itself, preventing the steady growth pattern.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>1 parent f4b7362 commit 45ee912
1 file changed
Lines changed: 8 additions & 3 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
373 | 373 | | |
374 | 374 | | |
375 | 375 | | |
376 | | - | |
377 | | - | |
| 376 | + | |
| 377 | + | |
| 378 | + | |
| 379 | + | |
| 380 | + | |
378 | 381 | | |
379 | 382 | | |
380 | 383 | | |
381 | 384 | | |
382 | 385 | | |
383 | 386 | | |
384 | | - | |
| 387 | + | |
385 | 388 | | |
| 389 | + | |
| 390 | + | |
386 | 391 | | |
387 | 392 | | |
388 | 393 | | |
| |||
0 commit comments