SQLite Forum


4 forum posts by user brodybits

22:45 Reply: Unexepected commit result with two threads application (artifact: 0c5764aa29 user: brodybits)

I made the test case below in TCL, which is partially based on the reproduction program in the ticket.

The test case demonstrates that if the bug fix is removed, the COMMIT would prematurely report SQLITE_OK, with the change not really committed.

I would love to see this or a similar test case added to the test suite and would be happy to sign a public domain statement, if needed.

# partially based on: test/lock.test

set testdir [file dirname $argv0]
source $testdir/tester.tcl

# Create an alternative connection to the database
do_test repeated-commit-busy-0 {
  sqlite3 db2 test.db
} {}

do_test repeated-commit-busy-1 {
  execsql {

  execsql {
    INSERT INTO t1 VALUES(1, 'one');
    INSERT INTO t1 VALUES(2, 'two');
    INSERT INTO t1 VALUES(3, 'three');

  execsql { SELECT * FROM t1 }
} {1 one 2 two 3 three}

do_test repeated-commit-busy-2 {
  set STMT2 [sqlite3_prepare db2 "SELECT * FROM t1" -1 TAIL]
  execsql { SELECT NULL } db2
} {{}}

do_test repeated-commit-busy-3 {
  set STMT1 [sqlite3_prepare db "COMMIT" -1 TAIL]
  execsql { SELECT NULL }
} {{}}

# start reading as if in thread 2
do_test repeated-commit-busy-4 {
  sqlite3_step $STMT2

# update from thread 1,
# should be blocked as busy
do_test repeated-commit-busy-5 {
  execsql {
    INSERT INTO t1 VALUES(4, 'four');
  sqlite3_step $STMT1

# should be blocked as busy over and over
for {set i 0} {$i < 10} {incr i} {
  do_test repeated-commit-busy-repeat-$i {
    sqlite3_step $STMT1

# release the read lock
do_test repeated-commit-busy-finalize-1 {
  sqlite3_finalize $STMT2

# should now be able to commit the update
do_test repeated-commit-busy-finalize-2 {
  sqlite3_step $STMT1

# and see the update
do_test repeated-commit-busy-final-check-1 {
  execsql { SELECT * FROM t1 }
} {1 one 2 two 3 three 4 four}
22:23 Reply: Unexepected commit result with two threads application (artifact: cf6696cc8c user: brodybits)

but if sqlite3_busy_timeout was 3 seconds, and I tried to repeat the step, the issue seemed to return

Do you mean that "the issue seemed to return" even with the check-in applied, or only without the bug fix?

18:23 Reply: Unexepected commit result with two threads application (artifact: c8558bdde4 user: brodybits)

The following mutation does not seem to trigger any test failures for me (I tried running make test twice with this change):

Index: src/vdbe.c
--- src/vdbe.c
+++ src/vdbe.c
@@ -701,11 +701,10 @@
     ** sqlite3_column_text16() failed.  */
     goto no_mem;
   assert( p->rc==SQLITE_OK || (p->rc&0xff)==SQLITE_BUSY );
   testcase( p->rc!=SQLITE_OK );
-  p->rc = SQLITE_OK;
   assert( p->bIsReader || p->readOnly!=0 );
   p->iCurrentTime = 0;
   assert( p->explain==0 );
   p->pResultSet = 0;
   db->busyHandler.nBusy = 0;

The test program in the ticket does seem to reproduce the issue with the above mutation.

00:46 Post: SQLITE_MAX_VARIABLE_NUMBER outdated in documentation (artifact: 2d7907422c user: brodybits)

From SQLite 3.32.0 and sqlite-amalgamation I can see that the default SQLITE_MAX_VARIABLE_NUMBER value was increased to 32766.

But it does not seem to be updated in the documentation here: https://www.sqlite.org/limits.html#max_variable_number