STOR-5107: Make process wide SQLite memory limits configurable#6597
STOR-5107: Make process wide SQLite memory limits configurable#6597joshthoward wants to merge 2 commits intomainfrom
Conversation
There was a problem hiding this comment.
I'm Bonk, and I've done a quick review of your PR.
This PR makes the SQLite process-wide hard heap limit configurable by adding a sqliteMaxMemoryPerProcessBytes parameter to the SqliteDatabase constructor, replacing the previous autogate-driven logic.
I found two bugs and one cleanup item, ranked by severity:
-
[High] Uninitialized member read —
sqliteMaxMemoryPerProcessBytesis added as a member field and a constructor parameter, but is not initialized in the member initializer list (line 578-583 of sqlite.c++). It is then read insetupSecurity()via thestatic bool doOncelambda duringinit(), which is called from the constructor body. This is a read of an indeterminate value. Fix: addsqliteMaxMemoryPerProcessBytes(sqliteMaxMemoryPerProcessBytes),to the initializer list aftersqliteMaxMemoryBytes(sqliteMaxMemoryBytes),. -
[Medium]
[&]capture onstaticlocal is a latent hazard — The lambda was changed from[]()(captureless) to[&](). Sincestaticlocals initialize exactly once this works, but[&]capturesthisby reference — that reference is dangling after the first constructor returns. Any future refactor that re-invokes this code path would hit UB. Prefer[sqliteMaxMemoryPerProcessBytes]()(capture by value). -
[Low] Dead autogate —
INCREASE_SQLITE_HARD_HEAP_LIMITinautogate.h/autogate.c++is no longer referenced. Consider cleaning it up in this PR or a follow-up.
See inline comments for suggested fixes.
|
The review was posted successfully. Here's a summary of what I found: 3 issues on PR #6597, ranked by severity:
|
535f85b to
22a7b58
Compare
Merging this PR will improve performance by 39.34%
|
| Benchmark | BASE |
HEAD |
Efficiency | |
|---|---|---|---|---|
| ⚡ | simpleStringBody[Response] |
27.2 µs | 19.5 µs | +39.34% |
Comparing jhoward/STOR-5107 (22a7b58) with main (22c1ca0)
Footnotes
-
129 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩
No description provided.