From 5f6a0d2342323541e44ff2f1e7329053d0263800 Mon Sep 17 00:00:00 2001 From: Eric Wong Date: Tue, 25 Aug 2020 03:02:47 +0000 Subject: over+msgmap: respect WAL journal_mode if set WAL actually seems to have ideal locking characteristics given concurrency problems I'm experiencing with --reindex running in parallel with expensive read-only SQLite queries: Unfortunately, we cannot blindly use WAL while preserving compatibility with existing setups nor our guarantees that read-only daemons are indeed "read-only". However, respect an user's the choice to set WAL on their own if they're comfortable with giving -nntpd/-httpd/-imapd processes write permission to the directory storing SQLite DBs. --- lib/PublicInbox/OverIdx.pm | 5 ----- 1 file changed, 5 deletions(-) (limited to 'lib/PublicInbox/OverIdx.pm') diff --git a/lib/PublicInbox/OverIdx.pm b/lib/PublicInbox/OverIdx.pm index d42d6fe7..9f4a56fb 100644 --- a/lib/PublicInbox/OverIdx.pm +++ b/lib/PublicInbox/OverIdx.pm @@ -23,11 +23,6 @@ sub dbh_new { my ($self) = @_; my $dbh = $self->SUPER::dbh_new($self->{-no_fsync} ? 2 : 1); - # TRUNCATE reduces I/O compared to the default (DELETE) - # We do not use WAL since we're optimized for read-only ops, - # (and read-only requires SQLite 3.22.0 (2018-01-22)). - $dbh->do('PRAGMA journal_mode = TRUNCATE'); - # 80000 pages (80MiB on SQLite <3.12.0, 320MiB on 3.12.0+) # was found to be good in 2018 during the large LKML import # at the time. This ought to be configurable based on HW -- cgit v1.2.3-24-ge0c7