Hard coded sqlite connection size limits limits concurrency and varies with password presence #1604
Labels
No labels
DB & Storage
Deployment
Error Handling & Logging
Maintenance
Payment Backend
backport
backport v0.13.x
backport v0.14.x
backport v0.15.x
bindings
blocked
bug
cdk-sql
ci
cli
deps
documentation
duplicate
enhancement
good first issue
help wanted
invalid
keep-open
ldk-node-ui
migrations
mint
mutation-testing
needs rebase
needs review
new nut
nut change
question
ready
rust-version
rustfmt
stacked hold
stale
testing
wallet
weekly-report
wontfix
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
cashubtc/cdk#1604
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The current SQLite connection sets the max number of connections based on the presence of a password. I don't see why this is the case having a password should not determine the number of connections we have.
Since the database is configured with pragma journal_mode = WAL (Write-Ahead Logging), SQLite is capable of handling multiple concurrent readers. Limiting the pool to a single connection for unencrypted databases serializes all operations, negating the performance benefits of WAL mode, while encrypted databases arbitrarily receive a higher limit.
I think we should set this to some more reasonable number and in the mint we could even reuse the connection limit setting we have for psgl.
github.com/cashubtc/cdk@3e6474bbd9/crates/cdk-sqlite/src/common.rs (L24-L31)The test restore seems to often fail with timeout issues in ci, I am wondering if having more readers would help this?