Open omer9564 opened 15 hours ago
Hi @omer9564,
I realized that there are some bugs in managing the life cycle of Go structs and the underlying C pointer. We need to make sure that the QueryResult
and PreparedStatement
structs are closed first, then the Connection
can be closed, and finally Database
can be closed, but the callback function we defined in runtime.SetFinalizer
does not make such guarantee. I have fixed it in #22 by keeping reference pointers to ensure GC order and returning by pointer in all cases to avoid unexpected GC actions on copied structs. After this fix, I ran your script and it did not crash for > 30 minutes (it has not terminated yet, but I suppose the GC issue has been fixed). Since I realized it is not possible to re-release the Go package, and we need to make sure that all API binding have the same version as the main project, I am not releasing a new stable version for now, but you should be able to test the fix by go get github.com/kuzudb/go-kuzu@master
.
Hey @mewim , Thanks for the quick response. I will check it out later on this week.
Hi @omer9564,
I am not concerning the API change. However, in general, as a principle of kuzu project, we make the versions of the database core, CLI, and all the API bindings consistent, so if we release v0.6.1, we need to release it for all the components. I will coordinate with the team to see if there are any additional fixes and changes in other client APIs need to come in before making a release.
Yes I noticed it after re-reading your comment again so I went ahead and deleted this part from my comment 😅 Anyway because golang "releases" are based on git tags, I think deleting and recreating the tag on the latest commit might do what you aim for ( which is fixing the 0.6.0 tag in the golang project alone ) but not sure if this is also a nice solution
I'm getting a panic in when running "stress" on the kuzudb using the go-kuzu package.
The code I'm using to do this is ( I also tried building the queries myself instead of using the query builder, it didn't help ): Worth pointing out - increasing the sleepMiliseconds does make this happen less frequently. Also tried saving the results in some slice as I saw in the panic something related to the GC which didn't help