Fix startup WAL race and stale sidecar I/O errors

Enabling WAL per pooled connection raced several concurrent journal-mode
switches when r2d2 eagerly opens the pool at startup, producing transient
"disk I/O error" and "database is locked" failures. WAL is a persistent
property of the database file, so enable it once in init_db (before the
scanners and web server start) and keep only the genuinely per-connection
pragmas (busy_timeout, synchronous, foreign_keys) in the pool initializer.

Also remove the -wal/-shm sidecars in run.sh: deleting oott.db but leaving
a stale write-ahead log behind makes SQLite open the fresh database against
an orphaned log and fail with "disk I/O error".

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
rzuasti
2026-06-06 09:46:44 -04:00
co-authored by Claude Opus 4.8
parent 393e545501
commit 5c5087d687
2 changed files with 20 additions and 8 deletions
+4 -1
View File
@@ -1,3 +1,6 @@
#!/bin/sh
sudo rm -f oott.db
# Remove the database and its WAL sidecars. Deleting oott.db but leaving a stale -wal/-shm
# behind (e.g. from a previous run killed before a checkpoint) makes SQLite open the fresh
# database against an orphaned write-ahead log and fail with "disk I/O error".
sudo rm -f oott.db oott.db-wal oott.db-shm
sudo CARGO_HOME=$HOME/.cargo cargo run