From e26c19539c08d2b2fced778ca76b486deffa6b7c Mon Sep 17 00:00:00 2001 From: Brandur Date: Wed, 21 May 2025 22:48:53 -0700 Subject: [PATCH] Expand SQLite comment to talk about `busy_timeout` Another small one. While writing documentation for SQLite tonight I tried using `busy_timeout` as an alternative to setting a maximum of one active connection. It kind of works, but I found overall that I'd still get `SQLITE_BUSY` errors with `busy_timeout` once iterating the test suite at higher counts like `-count 100`. Overall, I think the single active connection is still the way to go. Here, add a note on that so I won't forget about this in the future. --- rivershared/riversharedtest/riversharedtest.go | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/rivershared/riversharedtest/riversharedtest.go b/rivershared/riversharedtest/riversharedtest.go index 90f8f477..a7ed9fb2 100644 --- a/rivershared/riversharedtest/riversharedtest.go +++ b/rivershared/riversharedtest/riversharedtest.go @@ -122,6 +122,10 @@ func DBPoolSQLite(ctx context.Context, tb testing.TB, schema string) *sql.DB { // anyway. See for example: // // https://news.ycombinator.com/item?id=30369095 + // + // An alternative approach is to increase `PRAGMA busy_timeout`, but I've + // found that we still run into `SQLITE_BUSY` errors with that at higher + // iteration counts like `-run TestClientWithDriverRiverSQLite -count 100`. dbPool.SetMaxOpenConns(1) // This innocuous line turns out to be quite important at the tail.