[pseudo] db: Use WAL mode for on-disk database

Submitted by Joshua Watt on July 31, 2020, 2 p.m. | Patch ID: 174953

Details

Message ID 20200731140043.29659-1-JPEWhacker@gmail.com
State New
Headers show

Commit Message

Joshua Watt July 31, 2020, 2 p.m.
If the in-memory database is not being used, enable WAL mode on the
database to ensure that the database is resilient to pseudo shutting
down unexpectedly (or being terminated by the OS). This allows projects
to make the reliability vs. performance tradeoff: If they want
performance they can use the in-memory database; if they want resilience
they can disable the in-memory database and WAL will prevent database
corruption.

Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
---
 pseudo_db.c | 15 ++++++++++++++-
 1 file changed, 14 insertions(+), 1 deletion(-)

Patch hide | download patch | download mbox

diff --git a/pseudo_db.c b/pseudo_db.c
index 92e4f50..ebf6e08 100644
--- a/pseudo_db.c
+++ b/pseudo_db.c
@@ -158,11 +158,24 @@  static struct sql_index {
 
 static char *file_pragmas[] = {
 	"PRAGMA legacy_file_format = OFF;",
-	"PRAGMA journal_mode = OFF;",
+#ifdef USE_MEMORY_DB
 	/* the default page size produces painfully bad behavior
 	 * for memory databases with some versions of sqlite.
 	 */
 	"PRAGMA page_size = 8192;",
+	"PRAGMA journal_mode = OFF;",
+#else
+        /* Use WAL mode when using the on-disk database. If user care about
+         * performance, they can use the in-memory database, but if they care
+         * more about resilience, they can disable it and WAL mode will prevent
+         * corruption of the on-disk database (for a slight performance
+         * penalty). Note that the database still keeps synchronous to OFF,
+         * meaning its resilient to the pseudo process crashing or being killed
+         * unexpectedly, but not to the OS crashing and losing buffered disk
+         * state
+         */
+	"PRAGMA journal_mode = WAL;",
+#endif
 	"PRAGMA locking_mode = EXCLUSIVE;",
 	/* Setting this to NORMAL makes pseudo noticably slower
 	 * than fakeroot, but is perhaps more secure.  However,