blob: 0792c9aae00501fb8e70c274a5563f7fe36ef751 (
plain)
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}
#---------------------------------------------------------------
# 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
|
