fix: default sqlite journal mode to WAL#37758
Conversation
DELETE journal mode serializes every read against every write on the same file, so concurrent issue creation with the async issue indexer reading in the background can exceed the 5s busy timeout and return SQLITE_BUSY. WAL lets readers and one writer coexist, removing the contention. Also fix `testAPICreateIssueParallel`: `wg.Done()` lived inside the subtest closure, so a `t.FailNow` from `MakeRequest` skipped it and hung `wg.Wait` until the 50min job timeout. Moving it to a deferred call on the outer goroutine makes any future flake fail fast. The obsolete `time.Sleep(100ms)` workaround for the old mattn cgo `unlock_notify` bug is gone too. Drawbacks of WAL as default for existing installs: - backups via `cp gitea.db` no longer capture consistent state; must include `-wal`/`-shm` siblings or use `sqlite3 .backup` - WAL needs `mmap`, so NFS/SMB-hosted databases are unsupported - once a DB is opened in WAL it persists; rollback needs an explicit `PRAGMA journal_mode=DELETE` Co-Authored-By: Claude (Opus 4.7) <noreply@anthropic.com>
GiteaBot
added
the
lgtm/need 2
github-actions
Bot
added
the
docs-update-needed
|
Is it compatible between wal and non wal? |
|
But if user switch to non-wal, the problem is still there. |
wxiaoguang
left a comment
wxiaoguang
left a comment
There was a problem hiding this comment.
- default mode shouldn't be changed if there is no strong requirement from end users
- the comments and Sleep should be kept because the mattn driver is still there
- the test case should use "assert" but not "require" in the go routine
|
Alternatively, we could just make only the integration tests use to WAL for stability. My impression is that WAL is safe and a perf improvement in all scenarios, the more busy the database is, the more improvement. |
Show me that WAL really reduces the CI time or at least it reduces the time for the go routines. |
|
Original motivivation here was to fix the test flake seen in https://github.com/go-gitea/gitea/actions/runs/26009967009/job/76448592797, the change here makes it not hang anymore. Using WAL should stabilize the test, if we stay on DELETE, another fix needs to be found. |
It is just your hallucination
The root cause of "hang" is the incorrect "require" usages in the testing helper functions. -> chore: fix tests #37760 |
|
Keep it for now. |
5 participants
DELETE journal mode serializes readers against writers on the same file. Concurrent issue creation plus the async indexer reading in the background can exceed the 5s busy timeout and return
SQLITE_BUSY. WAL lets readers and one writer coexist.Also fix
testAPICreateIssueParallel:wg.Done()lived inside the subtest, so at.FailNowskipped it and hungwg.Waituntil the job timeout (the symptom in https://github.com/go-gitea/gitea/actions/runs/26009967009/job/76448592797). Move it to adeferon the outer goroutine. The obsolete 100ms sleep workaround for the old mattnunlock_notifybug is removed — modernc isn't affected.Drawbacks of WAL as default for existing installs
cp gitea.dbneed to include-wal/-shmor usesqlite3 .backupmmap, so NFS/SMB-hosted DBs are unsupportedPRAGMA journal_mode=DELETEThe example config notes when to opt back to DELETE.
This PR was written with the help of Claude Opus 4.7