From 0d762acf7ebf2406dc4f0ad167b580e3a3801f1e Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Mon, 17 Oct 2022 15:08:54 -0400 Subject: [PATCH] update comment, probably not a sqlite bug Sqlite's page documenting WAL mode changed in Oct 2016 to mention ways that queries could fail with SQLITE_BUSY. http://web.archive.org/web/20161009044054/http://www.sqlite.org:80/wal.html Probably not cooincidentally, I emailed sqlite-users about such a situation in Feb 2015. https://www.mail-archive.com/sqlite-users@mailinglists.sqlite.org/msg90580.html Noone ever replied to me, but at least now I understand why it does that. Since it's documented now, it's no longer a bug. --- Database/Handle.hs | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Database/Handle.hs b/Database/Handle.hs index b0c9786974..ce22d0a661 100644 --- a/Database/Handle.hs +++ b/Database/Handle.hs @@ -148,8 +148,8 @@ workerThread db tablename jobs = newconn -- Like runSqlite, but more robust. -- -- New database connections can sometimes take a while to become usable. --- This may be due to WAL mode recovering after a crash, or perhaps a bug --- like described in blob 500f777a6ab6c45ca5f9790e0a63575f8e3cb88f. +-- This may be due to WAL mode recovering after a crash, or perhaps a +-- situation like described in blob 500f777a6ab6c45ca5f9790e0a63575f8e3cb88f. -- So, loop until a select succeeds; once one succeeds the connection will -- stay usable. --