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 |
Timelines: | family | ancestors | descendants | both | trunk |
Files: | files | file ages | folders |
SHA3-256: |
5a12db75d1da65daa92413a6b5892309 |
User & Date: | dan 2018-07-03 20:17:27.649 |
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: e6108047cb 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: 221ff63e79 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: 32924446db 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: 5a12db75d1 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: b656364738 user: dan tags: trunk) | |
Changes
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 |