duckdb / duckdb-rs

Ergonomic bindings to duckdb for Rust
MIT License
511 stars 113 forks source link

Proper way of creating a static connection pool with r2d2 #278

Closed mgrazianoc closed 8 months ago

mgrazianoc commented 8 months ago

My version:

duckdb = { version = "0.10.1", features = ["bundled", "r2d2"] }
r2d2 = "0.8.10"

I have the following setup for creating a connection pool with r2d2 feature crate:

pub static DUCKDB_CONN_POOL: Lazy<Pool<DuckdbConnectionManager>> = Lazy::new(|| {
    let duckdb_manager = duckdb::DuckdbConnectionManager::memory().expect("DuckDB in-memory");
    let pool = r2d2::Pool::builder().max_size(15).build(duckdb_manager).expect("r2d2 connection pool");
    tracing::info!("NEW DUCKDB CONN POLL CREATED");
    pool
});

It is supposed to be singleton, where once created, would live the whole application lifetime, offering connections from the pool. I'm having some issues, though.

  1. Secrets are being ignored. In order for them to properly work, I need to: a. get a connection from the pool; b. configure the secrets (for R2/S3); c. immediately get another connection from the pool, and only this one will work with the secrets;
  2. More than a single instance of a DB seems to be created? a. I'm not sure if that is related with the first issue, but subsequente calls from the pooled connections cannot see previously created tables. As if like they don't exist.

Is there something I'm seeing?

Swoorup commented 7 months ago

Did you manage to fix this issue @mgrazianoc ? Wonder if this is related. https://github.com/marcboeker/go-duckdb/pull/61

mgrazianoc commented 7 months ago

Tbh, I've gave up using a connection pool, and just locked the single connection behind a private Arc Mutex. Not ideal, but is working for the small cases rn