feat: expose various low level memory management menthods#3895
feat: expose various low level memory management menthods#3895adriangb wants to merge 3 commits into
Conversation
SQLite's highwater marks can be 0 when no tracking has occurred yet, even if current values are non-zero. Update test assertions to handle this expected behavior correctly.
| /// | ||
| /// See: https://www.sqlite.org/c3ref/hard_heap_limit64.html | ||
| pub fn soft_heap_limit(&mut self, limit: i64) -> i64 { | ||
| unsafe { sqlite3_soft_heap_limit64(limit) } |
There was a problem hiding this comment.
The very first line of the linked documentation says:
These interfaces impose limits on the amount of heap memory that will be by all database connections within a single process.
So saying it sets it for the current thread, or having it as a method on the connection. is very misleading.
It should be a free function, or perhaps an associated method of the Sqlite type. Probably a free function.
Passing a negative number just gets the heap limit and doesn't set it, which also needs to be documented.
A more Rust-y API would be something like limit: Option<NonZeroU64>, returning an error if it's greater than i64::MAX (or using a wrapper type with fallible constructors), and providing a separate getter function, but I don't know if we need to go that far. I'd kind of like to sleep on it, though.
| /// | ||
| /// Returns the number of bytes of memory released. | ||
| /// | ||
| /// See: https://www.sqlite.org/c3ref/release_memory.html |
There was a problem hiding this comment.
This links to the wrong page. It should be: https://www.sqlite.org/c3ref/db_release_memory.html
|
@adriangb do you have time to rebase this and fix the CI failures? There are lint errors that need to be addressed: |
|
Closing to clear out the PR queue. Feel free to open a new PR after rebasing and fixing CI failures. |
I'm diagnosing memory usage in an application, I think these would be useful to have.