From f77b610e447144eeb7f522737dd0e6bde242441c Mon Sep 17 00:00:00 2001
From: dan <dan@noemail.net>
Date: Mon, 27 Oct 2014 11:25:28 +0000
Subject: [PATCH] Add test file e_wal.test.

FossilOrigin-Name: fc6920b5483eeeb06a474ff399a21afa51dc4859
---
 manifest        |  13 +--
 manifest.uuid   |   2 +-
 test/e_wal.test | 229 ++++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 237 insertions(+), 7 deletions(-)
 create mode 100644 test/e_wal.test

diff --git a/manifest b/manifest
index 6d8395af5e..6c3a597a05 100644
--- a/manifest
+++ b/manifest
@@ -1,5 +1,5 @@
-C Increase\sthe\sresolution\sof\sthe\ssecond\sparameter\sto\sthe\slikelihood()\sSQL\nfunction\s(the\sprobability\svalue)\sso\sthat\sit\scan\shandle\sprobabilities\nas\ssmall\sas\s0.00000001.\s\sFormerly,\sit\sran\sout\sof\sprecision\sat\s0.001.
-D 2014-10-25T13:42:16.126
+C Add\stest\sfile\se_wal.test.
+D 2014-10-27T11:25:28.528
 F Makefile.arm-wince-mingw32ce-gcc d6df77f1f48d690bd73162294bbba7f59507c72f
 F Makefile.in cf57f673d77606ab0f2d9627ca52a9ba1464146a
 F Makefile.linux-gcc 91d710bdc4998cb015f39edf3cb314ec4f4d7e23
@@ -466,6 +466,7 @@ F test/e_select2.test aceb80ab927d46fba5ce7586ebabf23e2bb0604f
 F test/e_update.test 312cb8f5ccfe41515a6bb092f8ea562a9bd54d52
 F test/e_uri.test 5ae33760fb2039c61aa2d90886f1664664173585
 F test/e_vacuum.test 5bfbdc21b65c0abf24398d0ba31dc88d93ca77a9
+F test/e_wal.test 0967f0b8f1dfda871dc7b9b5574198f1f4f7d69a
 F test/enc.test e54531cd6bf941ee6760be041dff19a104c7acea
 F test/enc2.test 83437a79ba1545a55fb549309175c683fb334473
 F test/enc3.test 90683ad0e6ea587b9d5542ca93568af9a9858c40
@@ -1206,7 +1207,7 @@ F tool/vdbe_profile.tcl 67746953071a9f8f2f668b73fe899074e2c6d8c1
 F tool/warnings-clang.sh f6aa929dc20ef1f856af04a730772f59283631d4
 F tool/warnings.sh 0abfd78ceb09b7f7c27c688c8e3fe93268a13b32
 F tool/win/sqlite.vsix deb315d026cc8400325c5863eef847784a219a2f
-P b9ad601eab1d7298d369267eb697c7fa1bc16985
-R 06fd31d9e4c300e561fccc4cf28a702b
-U drh
-Z 628a0c5751868817bd40f1740c611aef
+P 0f08924fe0c52a85a103f67bee9809e0f8f884b0
+R 770a2e0b8a993a6006545c850fbc4dd8
+U dan
+Z 70c394a419fcdd8591ee5c3f4c5346c4
diff --git a/manifest.uuid b/manifest.uuid
index 3804da23b9..a94336a518 100644
--- a/manifest.uuid
+++ b/manifest.uuid
@@ -1 +1 @@
-0f08924fe0c52a85a103f67bee9809e0f8f884b0
\ No newline at end of file
+fc6920b5483eeeb06a474ff399a21afa51dc4859
\ No newline at end of file
diff --git a/test/e_wal.test b/test/e_wal.test
new file mode 100644
index 0000000000..a5e074f49b
--- /dev/null
+++ b/test/e_wal.test
@@ -0,0 +1,229 @@
+# 2011 May 06
+#
+# The author disclaims copyright to this source code.  In place of
+# a legal notice, here is a blessing:
+#
+#    May you do good and not evil.
+#    May you find forgiveness for yourself and forgive others.
+#    May you share freely, never taking more than you give.
+#
+#***********************************************************************
+#
+
+set testdir [file dirname $argv0]
+source $testdir/tester.tcl
+set testprefix e_wal
+
+db close
+testvfs oldvfs -iversion 1
+
+
+# EVIDENCE-OF: R-58297-14483 WAL databases can be created, read, and
+# written even if shared memory is unavailable as long as the
+# locking_mode is set to EXCLUSIVE before the first attempted access.
+#
+# EVIDENCE-OF: R-00449-33772 This feature allows WAL databases to be
+# created, read, and written by legacy VFSes that lack the "version 2"
+# shared-memory methods xShmMap, xShmLock, xShmBarrier, and xShmUnmap on
+# the sqlite3_io_methods object.
+#
+# 1.1: "create" tests.
+# 1.2: "read" tests.
+# 1.3: "write" tests.
+#
+# All three done with VFS "oldvfs", which has iVersion==1 and so does
+# not support shared memory.
+# 
+sqlite3 db test.db -vfs oldvfs
+do_execsql_test 1.1.1 {
+  PRAGMA journal_mode = WAL;
+} {delete}
+do_execsql_test 1.1.2 {
+  PRAGMA locking_mode = EXCLUSIVE;
+  PRAGMA journal_mode = WAL;
+} {exclusive wal}
+do_execsql_test 1.1.3 {
+  CREATE TABLE t1(x, y);
+  INSERT INTO t1 VALUES(1, 2);
+} {}
+do_test 1.1.4 {
+  list [file exists test.db-shm] [file exists test.db-wal]
+} {0 1}
+
+do_test 1.2.1 {
+  db close
+  sqlite3 db test.db -vfs oldvfs
+  catchsql { SELECT * FROM t1 }
+} {1 {unable to open database file}}
+do_test 1.2.2 {
+  execsql { PRAGMA locking_mode = EXCLUSIVE }
+  execsql { SELECT * FROM t1 }
+} {1 2}
+do_test 1.2.3 {
+  list [file exists test.db-shm] [file exists test.db-wal]
+} {0 1}
+
+do_test 1.3.1 {
+  db close
+  sqlite3 db test.db -vfs oldvfs
+  catchsql { INSERT INTO t1 VALUES(3, 4) }
+} {1 {unable to open database file}}
+do_test 1.3.2 {
+  execsql { PRAGMA locking_mode = EXCLUSIVE }
+  execsql { INSERT INTO t1 VALUES(3, 4) }
+  execsql { SELECT * FROM t1 }
+} {1 2 3 4}
+do_test 1.3.3 {
+  list [file exists test.db-shm] [file exists test.db-wal]
+} {0 1}
+
+# EVIDENCE-OF: R-31969-57825 If EXCLUSIVE locking mode is set prior to
+# the first WAL-mode database access, then SQLite never attempts to call
+# any of the shared-memory methods and hence no shared-memory wal-index
+# is ever created.
+#
+db close
+sqlite3 db test.db
+do_execsql_test 2.1.1 {
+  PRAGMA locking_mode = EXCLUSIVE;
+  SELECT * FROM t1;
+} {exclusive 1 2 3 4}
+do_test 2.1.2 {
+  list [file exists test.db-shm] [file exists test.db-wal]
+} {0 1}
+
+# EVIDENCE-OF: R-36328-16367 In that case, the database connection
+# remains in EXCLUSIVE mode as long as the journal mode is WAL; attempts
+# to change the locking mode using "PRAGMA locking_mode=NORMAL;" are
+# no-ops.
+#
+do_execsql_test 2.2.1 {
+  PRAGMA locking_mode = NORMAL;
+  SELECT * FROM t1;
+} {exclusive 1 2 3 4}
+do_test 2.2.2 {
+  sqlite3 db2 test.db
+  catchsql {SELECT * FROM t1} db2
+} {1 {database is locked}}
+db2 close
+
+# EVIDENCE-OF: R-63522-46088 The only way to change out of EXCLUSIVE
+# locking mode is to first change out of WAL journal mode.
+#
+do_execsql_test 2.3.1 {
+  PRAGMA journal_mode = DELETE;
+  SELECT * FROM t1;
+} {delete 1 2 3 4}
+do_test 2.3.2 {
+  sqlite3 db2 test.db
+  catchsql {SELECT * FROM t1} db2
+} {1 {database is locked}}
+do_execsql_test 2.3.3 {
+  PRAGMA locking_mode = NORMAL;
+  SELECT * FROM t1;
+} {normal 1 2 3 4}
+do_test 2.3.4 {
+  sqlite3 db2 test.db
+  catchsql {SELECT * FROM t1} db2
+} {0 {1 2 3 4}}
+db2 close
+db close
+
+
+# EVIDENCE-OF: R-57239-11845 If NORMAL locking mode is in effect for the
+# first WAL-mode database access, then the shared-memory wal-index is
+# created.
+#
+do_test 3.0 {
+  sqlite3 db test.db
+  execsql { PRAGMA journal_mode = WAL }
+  db close
+} {}
+do_test 3.1 {
+  sqlite3 db test.db
+  execsql { SELECT * FROM t1 }
+  list [file exists test.db-shm] [file exists test.db-wal]
+} {1 1}
+
+# EVIDENCE-OF: R-13779-07711 As long as exactly one connection is using
+# a shared-memory wal-index, the locking mode can be changed freely
+# between NORMAL and EXCLUSIVE.
+#
+do_execsql_test 3.2.1 {
+  PRAGMA locking_mode = EXCLUSIVE;
+  PRAGMA locking_mode = NORMAL;
+  PRAGMA locking_mode = EXCLUSIVE;
+  INSERT INTO t1 VALUES(5, 6);
+} {exclusive normal exclusive}
+do_test 3.2.2 {
+  sqlite3 db2 test.db
+  catchsql { SELECT * FROM t1 } db2
+} {1 {database is locked}}
+
+# EVIDENCE-OF: R-10993-11647 It is only when the shared-memory wal-index
+# is omitted, when the locking mode is EXCLUSIVE prior to the first
+# WAL-mode database access, that the locking mode is stuck in EXCLUSIVE.
+#
+do_execsql_test 3.2.3 {
+  PRAGMA locking_mode = NORMAL;
+  SELECT * FROM t1;
+} {normal 1 2 3 4 5 6}
+do_test 3.2.4 {
+  catchsql { SELECT * FROM t1 } db2
+} {0 {1 2 3 4 5 6}}
+
+do_catchsql_test 3.2.5 {
+  PRAGMA locking_mode = EXCLUSIVE;
+  INSERT INTO t1 VALUES(7, 8);
+} {1 {database is locked}}
+
+db2 close
+
+# EVIDENCE-OF: R-46197-42811 This means that the underlying VFS must
+# support the "version 2" shared-memory.
+#
+# EVIDENCE-OF: R-55316-21772 If the VFS does not support shared-memory
+# methods, then the attempt to open a database that is already in WAL
+# mode, or the attempt convert a database into WAL mode, will fail.
+#
+db close
+do_test 3.4.1 {
+  sqlite3 db test.db -vfs oldvfs
+  catchsql { SELECT * FROM t1 }
+} {1 {unable to open database file}}
+db close
+do_test 3.4.2 {
+  forcedelete test.db2
+  sqlite3 db test.db2 -vfs oldvfs
+  catchsql { PRAGMA journal_mode = WAL }
+} {0 delete}
+db close
+
+
+# EVIDENCE-OF: R-22428-28959 To prevent older versions of SQLite from
+# trying to recover a WAL-mode database (and making matters worse) the
+# database file format version numbers (bytes 18 and 19 in the database
+# header) are increased from 1 to 2 in WAL mode.
+#
+reset_db
+do_execsql_test 4.1.1 { CREATE TABLE t1(x, y) }
+do_test 4.1.2 { hexio_read test.db 18 2 } {0101}
+do_execsql_test 4.1.3 { PRAGMA journal_mode = wAL } {wal}
+do_test 4.1.4 { hexio_read test.db 18 2 } {0202}
+
+
+# EVIDENCE-OF: R-02535-05811 One can explicitly change out of WAL mode
+# using a pragma such as this: PRAGMA journal_mode=DELETE;
+#
+do_execsql_test 4.2.1 { INSERT INTO t1 VALUES(1, 1); } {}
+do_test 4.2.2 { file exists test.db-wal } {1}
+do_execsql_test 4.2.3 { PRAGMA journal_mode = delete } {delete}
+do_test 4.2.4 { file exists test.db-wal } {0}
+
+# EVIDENCE-OF: R-60175-02388 Deliberately changing out of WAL mode
+# changes the database file format version numbers back to 1 so that
+# older versions of SQLite can once again access the database file.
+#
+do_test 4.3 { hexio_read test.db 18 2 } {0101}
+
+finish_test