sqlite/test/tkt3793.test
shane 739a277031 Fix a couple of Windows only issues with test scripts. (CVS 6698)
FossilOrigin-Name: 0f6bc5e1ba6937b36df08ed3b5903839389021bb
2009-06-01 16:42:17 +00:00

120 lines
3.9 KiB
Plaintext

# 2009 April 10
#
# 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.
#
#***********************************************************************
# This file implements regression tests for SQLite library.
#
# This file implements tests to verify that ticket #3793 has been
# fixed.
#
# $Id: tkt3793.test,v 1.2 2009/06/01 16:42:18 shane Exp $
set testdir [file dirname $argv0]
source $testdir/tester.tcl
ifcapable !shared_cache||!attach {
finish_test
return
}
set ::enable_shared_cache [sqlite3_enable_shared_cache 1]
do_test tkt3793-1.1 {
# This is taken from shared.test. The Windows VFS expands
# ./test.db (and test.db) to be the same thing so the path
# matches and they share a cache. By changing the case
# for Windows platform, we get around this and get a separate
# connection.
if {$::tcl_platform(platform)=="unix"} {
sqlite3 db1 test.db
sqlite3 db2 test.db
} else {
sqlite3 db1 TEST.DB
sqlite3 db2 TEST.DB
}
execsql {
BEGIN;
CREATE TABLE t1(a, b);
CREATE TABLE t2(a PRIMARY KEY, b);
INSERT INTO t1 VALUES(randstr(50,50), randstr(50,50));
INSERT INTO t1 SELECT randstr(50,50), randstr(50,50) FROM t1;
INSERT INTO t1 SELECT randstr(50,50), randstr(50,50) FROM t1;
INSERT INTO t1 SELECT randstr(50,50), randstr(50,50) FROM t1;
INSERT INTO t1 SELECT randstr(50,50), randstr(50,50) FROM t1;
INSERT INTO t1 SELECT randstr(50,50), randstr(50,50) FROM t1;
INSERT INTO t1 SELECT randstr(50,50), randstr(50,50) FROM t1;
INSERT INTO t1 SELECT randstr(50,50), randstr(50,50) FROM t1;
INSERT INTO t1 SELECT randstr(50,50), randstr(50,50) FROM t1;
INSERT INTO t1 SELECT randstr(50,50), randstr(50,50) FROM t1;
INSERT INTO t1 SELECT randstr(50,50), randstr(50,50) FROM t1;
INSERT INTO t2 SELECT * FROM t1;
COMMIT;
}
} {}
proc busyhandler {db args} { set ::busyconnection $db ; return 1 }
db2 busy {busyhandler db2}
db1 busy {busyhandler db1}
# Establish a read-lock on the database file using connection [db].
#
do_test tkt3793-1.2 {
execsql {
BEGIN;
SELECT count(*) FROM t1;
}
} {1024}
# Set the size of the cache shared by [db1] and [db2] to 10. Then update
# more than 10 pages of table t1. At this point the shared-cache will
# hold a RESERVED lock on the database file. Even though there are now
# more than 10 dirty pages in memory, it cannot upgrade to an EXCLUSIVE
# lock because of the read-lock held by [db].
#
do_test tkt3793-1.3 {
execsql {
PRAGMA cache_size = 10;
BEGIN;
UPDATE t1 SET b = randstr(50,50);
} db1
} {}
set x 0
# Run one SELECT query on the shared-cache using [db1], then from within
# the callback run another via [db2]. Because of the large number of dirty
# pages within the cache, each time a new page is read from the database
# SQLite will attempt to upgrade to an EXCLUSIVE lock, and hence invoke
# the busy-handler. The tests here verify that the correct busy-handler
# function is invoked (the busy-handler associated with the database
# connection that called sqlite3_step()). When bug #3793 existed, sometimes
# the [db2] busy-handler was invoked from within the call to sqlite3_step()
# associated with [db1].
#
# Note: Before the bug was fixed, if [db2] was opened with the "-fullmutex 1"
# option, then this test case would cause an assert() to fail.
#
set ::busyconnection db1
db1 eval {SELECT * FROM t2 ORDER BY a LIMIT 20} {
do_test tkt3793-2.[incr x] { set ::busyconnection } db1
set ::busyconnection db2
db2 eval { SELECT count(*) FROM t2 }
do_test tkt3793-2.[incr x] { set ::busyconnection } db2
set ::busyconnection db1
}
do_test tkt3793-3 {
db1 close
db2 close
} {}
sqlite3_enable_shared_cache $::enable_shared_cache
finish_test