TideSQL 4 PATCH (v4.6.1)

mysql-test/suite/tidesdb/r/tidesdb_pessimistic_shared.result

@@ -8,8 +8,8 @@ connect  s1, localhost, root,,;
 connect  s2, localhost, root,,;
 connect  s3, localhost, root,,;
 #
-# TEST 1: S / S compatible under REPEATABLE-READ
-#         Both s1 and s2 acquire S on the same row, neither blocks.
+# TEST 1: two plain reads under REPEATABLE-READ run concurrently,
+#         neither takes a lock and neither blocks.
 #
 connection s1;
 SET SESSION transaction_isolation = 'REPEATABLE-READ';
@@ -23,7 +23,7 @@ BEGIN;
 SELECT bal FROM acct WHERE id = 1;
 bal
 100
-# Both holders of S read successfully -- no deadlock, no block.
+# Both read successfully -- no lock, no block.
 connection default;
 SELECT bal FROM acct WHERE id = 1;
 bal
@@ -33,75 +33,55 @@ COMMIT;
 connection s2;
 COMMIT;
 #
-# TEST 2: X waits for S readers, then proceeds
-#         s1 + s2 hold S; s3 fires UPDATE that must wait until
-#         both readers release.
+# TEST 2: a plain read does NOT block a writer.  s1 keeps an open
+#         REPEATABLE-READ snapshot on the row while s3 updates it and
+#         commits immediately -- no lock wait.
 #
 connection s1;
 SET SESSION transaction_isolation = 'REPEATABLE-READ';
 BEGIN;
 SELECT bal FROM acct WHERE id = 1;
 bal
 100
-connection s2;
-SET SESSION transaction_isolation = 'REPEATABLE-READ';
-BEGIN;
-SELECT bal FROM acct WHERE id = 1;
-bal
-100
 connection s3;
 BEGIN;
 UPDATE acct SET bal = bal + 50 WHERE id = 1;
-connection s1;
-COMMIT;
-connection s2;
 COMMIT;
-connection s3;
+connection s1;
 COMMIT;
 connection default;
 # 100 + 50 = 150
 SELECT bal FROM acct WHERE id = 1;
 bal
 150
 #
-# TEST 3: writer fairness -- new S blocks behind a waiting X
-#         s1 holds S; s2 fires UPDATE (X-waiting); s3 fires a
-#         SELECT under REPEATABLE-READ that wants S.  s3 must
-#         NOT jump ahead of s2's queued X.
+# TEST 3: write-intent still locks.  s1 holds SELECT ... FOR UPDATE
+#         (X on the row); s3's UPDATE must wait until s1 commits.
 #
-UPDATE acct SET bal = 200 WHERE id = 1;
+connection default;
 connection s1;
-SET SESSION transaction_isolation = 'REPEATABLE-READ';
 BEGIN;
-SELECT bal FROM acct WHERE id = 1;
+SELECT bal FROM acct WHERE id = 1 FOR UPDATE;
 bal
-200
-connection default;
-connection s2;
+150
+connection s3;
 BEGIN;
 UPDATE acct SET bal = bal + 1 WHERE id = 1;
 connection default;
-connection s3;
-SET SESSION transaction_isolation = 'REPEATABLE-READ';
-BEGIN;
-SELECT bal FROM acct WHERE id = 1;
 connection s1;
 COMMIT;
-connection s2;
-COMMIT;
 connection s3;
 COMMIT;
 connection default;
-# s2 incremented 200 -> 201; s3 then read either 200 or 201 (both valid)
+# 150 + 1 = 151
 SELECT bal FROM acct WHERE id = 1;
 bal
-201
+151
 #
-# TEST 4: READ-COMMITTED reads take no lock
-#         s1 holds an uncommitted X via UPDATE; s2 under RC reads
-#         the latest committed value without blocking.
+# TEST 4: reads take no lock even with an uncommitted X held.  s1 holds
+#         an uncommitted UPDATE (X); s2 under READ-COMMITTED reads the
+#         latest committed value without blocking.
 #
-UPDATE acct SET bal = 300 WHERE id = 1;
 connection s1;
 BEGIN;
 UPDATE acct SET bal = bal + 100 WHERE id = 1;
@@ -110,15 +90,15 @@ SET SESSION transaction_isolation = 'READ-COMMITTED';
 BEGIN;
 SELECT bal FROM acct WHERE id = 1;
 bal
-300
+151
 COMMIT;
 connection s1;
 COMMIT;
 connection default;
-# 300 + 100 = 400
+# 151 + 100 = 251
 SELECT bal FROM acct WHERE id = 1;
 bal
-400
+251
 #
 # Cleanup
 #

mysql-test/suite/tidesdb/r/tidesdb_pessimistic_upgrade.result

@@ -7,7 +7,7 @@ INSERT INTO u VALUES (1, 100);
 connect  a, localhost, root,,;
 connect  b, localhost, root,,;
 #
-# Scenario 1, sole holder upgrades cleanly.
+# Scenario 1, a single transaction reads then writes the same row.
 #
 connection a;
 SET SESSION transaction_isolation = 'REPEATABLE-READ';
@@ -18,11 +18,14 @@ v
 UPDATE u SET v = v + 10 WHERE id = 1;
 COMMIT;
 connection default;
+# 100 + 10 = 110
 SELECT * FROM u WHERE id = 1;
 id	v
 1	110
 #
-# Scenario 2, two S holders, one tries to upgrade, must be rejected.
+# Scenario 2, two transactions read the row, then one writes it.  The
+#         plain reads take no lock, so the write acquires X and commits
+#         -- no upgrade, no deadlock.
 #
 connection a;
 SET SESSION transaction_isolation = 'REPEATABLE-READ';
@@ -38,15 +41,14 @@ v
 110
 connection a;
 UPDATE u SET v = v + 1 WHERE id = 1;
-ERROR 40001: Deadlock found when trying to get lock; try restarting transaction
-ROLLBACK;
+COMMIT;
 connection b;
 COMMIT;
 connection default;
-# Row 1 unchanged from scenario 2.
+# 110 + 1 = 111
 SELECT * FROM u WHERE id = 1;
 id	v
-1	110
+1	111
 disconnect a;
 disconnect b;
 connection default;

mysql-test/suite/tidesdb/r/tidesdb_vector.result

@@ -9,7 +9,7 @@ VECTOR INDEX (v)
 ) ENGINE=TidesDB;
 INSERT INTO docs VALUES (1, 'origin-x', Vec_FromText('[1.0, 0.0, 0.0, 0.0]'));
 INSERT INTO docs VALUES (2, 'origin-y', Vec_FromText('[0.0, 1.0, 0.0, 0.0]'));
-INSERT INTO docs VALUES (3, 'origin-z', Vec_FromText('[0.0, 0.0, 1.0, 0.0]'));
+INSERT INTO docs VALUES (3, 'origin-z', Vec_FromText('[0.0, 0.0, 1.0, 0.4]'));
 INSERT INTO docs VALUES (4, 'near-x',   Vec_FromText('[0.9, 0.1, 0.0, 0.0]'));
 INSERT INTO docs VALUES (5, 'center',   Vec_FromText('[0.5, 0.5, 0.5, 0.5]'));
 #

mysql-test/suite/tidesdb/t/tidesdb_concurrency.test

@@ -435,18 +435,57 @@ while ($i <= 200)
 
 --enable_query_log
 
-# Commit both
+# Commit both concurrently.  Under optimistic MVCC two transactions committing
+# at the same moment can lose to a retryable conflict (1180/1213) even on
+# disjoint keys, so the commit is allowed to return one of those and the losing
+# transaction is replayed -- exactly the deadlock-retry an application must do,
+# and what the sibling concurrency tests already codify.  The replay is
+# uncontended, so the 200-row set is preserved either way.
 connection bulk1;
 send COMMIT;
 
 connection bulk2;
 send COMMIT;
 
 connection bulk1;
+--error 0,ER_LOCK_DEADLOCK,ER_ERROR_DURING_COMMIT
 reap;
+let $err1= $mysql_errno;
 
 connection bulk2;
+--error 0,ER_LOCK_DEADLOCK,ER_ERROR_DURING_COMMIT
 reap;
+let $err2= $mysql_errno;
+
+if ($err1)
+{
+  connection bulk1;
+  BEGIN;
+  --disable_query_log
+  let $i= 1;
+  while ($i <= 100)
+  {
+    eval INSERT INTO stress_bulk VALUES ($i, CONCAT('b1_', $i));
+    inc $i;
+  }
+  --enable_query_log
+  COMMIT;
+}
+
+if ($err2)
+{
+  connection bulk2;
+  BEGIN;
+  --disable_query_log
+  let $i= 101;
+  while ($i <= 200)
+  {
+    eval INSERT INTO stress_bulk VALUES ($i, CONCAT('b2_', $i));
+    inc $i;
+  }
+  --enable_query_log
+  COMMIT;
+}
 
 # Bulk3: read while data settles
 connection bulk3;