Follow-up from PR #942 review (Murzik, non-blocking).
What #942 did: added PRAGMA busy_timeout=30000 to all 14 thread-local store connection factories, raising the lock wait from SQLite's 5s default.
Residual gap: the pragma is executed after PRAGMA journal_mode=WAL, so that first setup statement still runs under the 5s default. Same for anything else executed during connection setup before the timeout is applied.
Why it wasn't a blocker: WAL is already persistent and established before worker handles open, and a same-WAL journal_mode pragma returns immediately under a normal concurrent writer (probed during review). So the normal write-queue path — the one #942 targets — is fully covered.
When it would bite: obscure connection-opening / recovery cases where a lock is contended precisely during setup (e.g. another process mid-recovery or changing journal mode).
Fix options (either is fine):
- Move
PRAGMA busy_timeout=30000 above PRAGMA journal_mode=WAL in all 14 factories, or
- Pass
sqlite3.connect(path, timeout=30), which applies from the moment the connection opens and makes the pragma redundant for this purpose.
Option 2 is arguably cleaner (covers the connect itself), but changes the knob's provenance from SQL to the driver — worth one deliberate choice rather than mixing both.
Related: the shared-connection stores (pending thread-local batch migration) are still on the 5s default entirely; that's separate scope, not this issue.
Refs: #942, #956. busy_timeout, WAL persistence.
🤖 Opened by Barsik
Follow-up from PR #942 review (Murzik, non-blocking).
What #942 did: added
PRAGMA busy_timeout=30000to all 14 thread-local store connection factories, raising the lock wait from SQLite's 5s default.Residual gap: the pragma is executed after
PRAGMA journal_mode=WAL, so that first setup statement still runs under the 5s default. Same for anything else executed during connection setup before the timeout is applied.Why it wasn't a blocker: WAL is already persistent and established before worker handles open, and a same-WAL
journal_modepragma returns immediately under a normal concurrent writer (probed during review). So the normal write-queue path — the one #942 targets — is fully covered.When it would bite: obscure connection-opening / recovery cases where a lock is contended precisely during setup (e.g. another process mid-recovery or changing journal mode).
Fix options (either is fine):
PRAGMA busy_timeout=30000abovePRAGMA journal_mode=WALin all 14 factories, orsqlite3.connect(path, timeout=30), which applies from the moment the connection opens and makes the pragma redundant for this purpose.Option 2 is arguably cleaner (covers the connect itself), but changes the knob's provenance from SQL to the driver — worth one deliberate choice rather than mixing both.
Related: the shared-connection stores (pending thread-local batch migration) are still on the 5s default entirely; that's separate scope, not this issue.
Refs: #942, #956. busy_timeout, WAL persistence.
🤖 Opened by Barsik