Closed taniabogatsch closed 6 months ago
This is an update to the main PR message concerning my most recent commit.
func (s *stmt) execute(ctx context.Context, args []driver.NamedValue) (*C.duckdb_result, error)
from leaking memory on context errors (missing C.duckdb_destroy_result(&res)
).TestTypeNamesAndScanTypes
from leaking memory.README.md
that addresses memory allocations in go-duckdb. It explains why calling Close
is crucial in go-duckdb to avoid memory leaks. While adding that section, I also expanded the readme file to make coding patterns more explicit.Note: there are still a few leaks in the appender, which @maiadegraaf addresses in #150.
Thanks @taniabogatsch
This PR builds on the work of #151. See also my comment here.
Changes in this PR:
Connector
now exposes itsClose
method (done by @levakin). This PR contains the respective commits of #151.c.(io.Closer).Close()
is crucial to avoid memory leaks in the database objectClose
simplifies closing theConnector
for users, reducing the risk of leaks and increasing usabilitydb *C.duckdb_database
todb C.duckdb_database
in theConnector
because it is already a pointer (typedef struct _duckdb_database {void *__db;} * duckdb_database;
). Or was there a reason to store it as a pointer?C.duckdb_destroy_config(&config)
to more places to avoid leaksC.CString
, to the best of my knowledgeC.duckdb_set_config(config, C.CString("duckdb_api"), C.CString("go"))
C.duckdb_set_config(config, C.CString(k), C.CString(v[0]))
setConfig
, and I added explicit calls toC.free
cc @marcboeker @levakin