You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
SqliteConnectOptions::filename() doesn't set in_memory = true, which caused me all sorts of connection pool deadlocking issues in a larger project. Pull request being filed shortly.
Minimal Reproduction
Due to issue #2510 where in-memory SQLite databases appear to get wiped after being left idle for an extended period, I was doing a long-winded construction of the SqlitePool to use max_connections(1) as suggested.
let sqlite_opts = SqliteConnectOptions::new().filename(":memory:")// BUG: this does not set `in_memory = true`.create_if_missing(false);// max_connections = 1 to prevent the DB from being wiped randomly// issue: https://github.com/launchbadge/sqlx/issues/2510let pool = SqlitePoolOptions::new().max_connections(1).connect_with(sqlite_opts).await?;
Switching to this instantiation started giving me all sorts of weird deadlocking issues with a larger project, which changed the point of failure on a specific test depending on which order a single-threaded tokio::test runtime executed. I sadly have not been able to reproduce the deadlocking and pool timeouts on a smaller example or diagnose where the deadlock occurs, but I can reliably fix them by using SqliteConnectOptions::from_str(":memory:") instead.
Info
SQLx version: 0.7.4
SQLx features enabled: ["macros", "sqlite", "uuid", "runtime-tokio", "chrono"]
On second glance my pool timeout issue with .max_connections(1) still exists, but I still believe the PR could be worth merging for reasons outlined below.
The parsing code applies this logic for :memory: SQLite databases, which does not happen with a SqliteConnectOptions::new().filename(":memory:") instantiation and leads to issues where max_connections > 1.
Bug Description
SqliteConnectOptions::filename()
doesn't setin_memory = true
, which caused me all sorts of connection pool deadlocking issues in a larger project. Pull request being filed shortly.Minimal Reproduction
Due to issue #2510 where in-memory SQLite databases appear to get wiped after being left idle for an extended period, I was doing a long-winded construction of the SqlitePool to use
max_connections(1)
as suggested.Switching to this instantiation started giving me all sorts of weird deadlocking issues with a larger project, which changed the point of failure on a specific test depending on which order a single-threaded tokio::test runtime executed. I sadly have not been able to reproduce the deadlocking and pool timeouts on a smaller example or diagnose where the deadlock occurs, but I can reliably fix them by using
SqliteConnectOptions::from_str(":memory:")
instead.Info
["macros", "sqlite", "uuid", "runtime-tokio", "chrono"]
rustc --version
: rustc 1.76.0 (07dca489a 2024-02-04)The text was updated successfully, but these errors were encountered: