[PATCH] lei: sqlite: do not forcibly enable WAL

[PATCH] lei: sqlite: do not forcibly enable WAL

[Eric Wong]

I'm not sure why and I can no longer reproduce it; but I've
triggered a SIGBUS in the lei/store inside the WAL commit code
while writing to mail_sync.sqlite3 on my Debian (oldstable)
buster system.

It could be a problem with my ancient SSD, improper use on our
end, a bug fixed in a newer SQLite version, etc..  In any case,
lets minimize the risk and keep using TRUNCATE like we do with
the time-tested public-inbox-* stuff, but respect WAL if a user
wants to set it themselves.
---
 lib/PublicInbox/LeiMailSync.pm    | 5 ++++-
 lib/PublicInbox/LeiSavedSearch.pm | 5 +----
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/lib/PublicInbox/LeiMailSync.pm b/lib/PublicInbox/LeiMailSync.pm
index 5a10c127..dc4395f0 100644
--- a/lib/PublicInbox/LeiMailSync.pm
+++ b/lib/PublicInbox/LeiMailSync.pm
@@ -21,8 +21,11 @@ sub dbh_new {
 		sqlite_use_immediate_transaction => 1,
 	});
 	# no sqlite_unicode, here, all strings are binary
+	# TRUNCATE reduces I/O compared to the default (DELETE).
+	# Allow and preserve user-overridden WAL, but don't force it.
+	my $jm = $dbh->selectrow_array('PRAGMA journal_mode');
+	$dbh->do('PRAGMA journal_mode = TRUNCATE') if $jm ne 'wal';
 	create_tables($dbh) if $rw;
-	$dbh->do('PRAGMA journal_mode = WAL') if $creat;
 	$dbh->do('PRAGMA case_sensitive_like = ON');
 	$dbh;
 }
diff --git a/lib/PublicInbox/LeiSavedSearch.pm b/lib/PublicInbox/LeiSavedSearch.pm
index 96ff816e..8fcfa752 100644
--- a/lib/PublicInbox/LeiSavedSearch.pm
+++ b/lib/PublicInbox/LeiSavedSearch.pm
@@ -229,10 +229,7 @@ sub prepare_dedupe {
 		my $oidx = PublicInbox::OverIdx->new($self->{-ovf});
 		$oidx->{-no_fsync} = 1;
 		$oidx->dbh;
-		if ($creat) {
-			$oidx->{dbh}->do('PRAGMA journal_mode = WAL');
-			$oidx->eidx_prep; # for xref3
-		}
+		$oidx->eidx_prep if $creat; # for xref3
 		$oidx
 	};
 }

Re: [PATCH] lei: sqlite: do not forcibly enable WAL

[Eric Wong]

Eric Wong <e@80x24.org> wrote:
> It could be a problem with my ancient SSD, improper use on our
> end,

Yes, EDOOFUS :x
I suspect it was fixed in v2 of <20210917015644.32746-2-e@80x24.org>
("lei refresh-mail-sync: replace prune-mail-sync")

So I think lei will keep using WAL (and maybe start using mmap, too)