mirror of
https://github.com/sqlite/sqlite.git
synced 2024-11-29 00:12:23 +01:00
b07db116e7
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. FossilOrigin-Name: 221ff63e7902226ebf728bb7442727420636831163708f360724506ce9487ab6
98 lines
2.8 KiB
Plaintext
98 lines
2.8 KiB
Plaintext
# 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
|