/ Check-in [5a12db75]
Login
SQLite training in Houston TX on 2019-11-05 (details)
Part of the 2019 Tcl Conference

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:Test that a race condition can cause a "BEGIN EXCLUSIVE" to return SQLITE_BUSY_SNAPSHOT in wal mode.
Downloads: Tarball | ZIP archive | SQL archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA3-256: 5a12db75d1da65daa92413a6b5892309e9d9479bb3610764e1015abe5bf28dbe
User & Date: dan 2018-07-03 20:17:27
Context
2018-07-05
17:16
In wal mode, if a "BEGIN EXCLUSIVE" command (or any other command that upgrades from no transaction directly to a write transaction) hits an SQLITE_BUSY_SNAPSHOT error, change the error code to SQLITE_BUSY to indicate to the caller that the condition may be transient. check-in: e6108047 user: dan tags: trunk
15:46
In wal mode, if a "BEGIN EXCLUSIVE" command (or any other command that upgrades from no transaction directly to a write transaction) hits an SQLITE_BUSY_SNAPSHOT error, change the error code to SQLITE_BUSY to indicate to the caller that the condition may be transient. check-in: 221ff63e user: dan tags: exp-busy-snapshot-fix
2018-07-04
14:28
Experimental planner change to avoid a skip-scan if a regular index scan on the same index columns can be done instead. Leaf check-in: 32924446 user: dan tags: exp-avoid-expensive-skipscan
2018-07-03
20:17
Test that a race condition can cause a "BEGIN EXCLUSIVE" to return SQLITE_BUSY_SNAPSHOT in wal mode. check-in: 5a12db75 user: dan tags: trunk
2018-07-02
17:45
Fix a problem in the xInverse callback for the built-in sum() window function. check-in: b6563647 user: dan tags: trunk
Changes
Hide Diffs Unified Diffs Ignore Whitespace Patch

Added test/walprotocol2.test.



































































































































































































>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
# 2018 July 4
#
# 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
source $testdir/lock_common.tcl
source $testdir/wal_common.tcl
ifcapable !wal {finish_test ; return }

set testprefix walprotocol2

#-------------------------------------------------------------------------
# When recovering the contents of a WAL file, a process obtains the WRITER
# lock, then locks all other bytes before commencing recovery. If it fails
# to lock all other bytes (because some other process is holding a read
# lock) it should retry up to 100 times. Then return SQLITE_PROTOCOL to the 
# caller. Test this (test case 1.3).
#
# Also test the effect of hitting an SQLITE_BUSY while attempting to obtain
# the WRITER lock (should be the same). Test case 1.4.
# 
do_execsql_test 1.0 {
  PRAGMA journal_mode = wal;
  CREATE TABLE x(y);
  INSERT INTO x VALUES('z');
} {wal}

db close

proc lock_callback {method filename handle lock} {
  # puts "$method $filename $handle $lock"
}
testvfs T
T filter xShmLock 
T script lock_callback

sqlite3 db  test.db -vfs T
sqlite3 db2 test.db -vfs T

do_execsql_test 2.0 {
  SELECT * FROM x;
} {z}
do_execsql_test -db db2 2.1 {
  SELECT * FROM x;
} {z}

#---------------------------------------------------------------
# Attempt a "BEGIN EXCLUSIVE" using connection handle [db]. This
# causes SQLite to open a read transaction, then a write transaction.
# Rig the xShmLock() callback so that just before the EXCLUSIVE lock
# for the write transaction is taken, connection [db2] jumps in and
# modifies the database. This causes the "BEGIN EXCLUSIVE" to throw
# an SQLITE_BUSY_SNAPSHOT error.
#
proc lock_callback {method filename handle lock} {
  if {$lock=="0 1 lock exclusive"} {
    proc lock_callback {method filename handle lock} {}
    db2 eval { INSERT INTO x VALUES('y') }
  }
}
do_catchsql_test 2.2 {
  BEGIN EXCLUSIVE;
} {1 {database is locked}}
do_test 2.3 {
  sqlite3_extended_errcode db
} {SQLITE_BUSY_SNAPSHOT}

#---------------------------------------------------------------
# Same again, but with a busy-handler. This time, following the
# SQLITE_BUSY_SNAPSHOT error the busy-handler is invoked and then the 
# whole thing retried from the beginning. This time it succeeds.
#
proc lock_callback {method filename handle lock} {
  if {$lock=="0 1 lock exclusive"} {
    proc lock_callback {method filename handle lock} {}
    db2 eval { INSERT INTO x VALUES('x') }
  }
}
db timeout 10
do_catchsql_test 2.4 {
  BEGIN EXCLUSIVE;
} {0 {}}
do_execsql_test 2.5 {
  SELECT * FROM x;
  COMMIT;
} {z y x}

finish_test