[MDEV-20373] rocksdb.add_index_inplace fails randomly with wrong result with FORCE INDEX Created: 2019-08-18  Updated: 2023-12-05

Status: Stalled
Project: MariaDB Server
Component/s: Storage Engine - RocksDB
Affects Version/s: 10.3, 10.4, 10.5
Fix Version/s: 10.3

Type: Bug Priority: Major
Reporter: Michael Widenius Assignee: Sergei Petrunia
Resolution: Unresolved Votes: 0
Labels: None


 Description   

rocksdb.add_index_inplace 'write_prepared' w2 [ fail ]
CURRENT_TEST: rocksdb.add_index_inplace
--- D:/winx64-packages/build/src/storage/rocksdb/mysql-test/rocksdb/r/add_index_inplace.result	2019-08-16 07:57:33.000000000 +0000
+++ D:\winx64-packages\build\src\storage\rocksdb\mysql-test\rocksdb\r\add_index_inplace.reject	2019-08-16 11:32:23.060422600 +0000
@@ -322,7 +322,7 @@
 1
 SELECT COUNT(*) FROM t1 FORCE INDEX(kj);
 COUNT(*)
-1
+0
 DROP TABLE t1;
 disconnect con2;
 # Establish connection con1 (user=root)

This happened for me in buildbot in 10.5 yesterday and according to cross reference report happens quite often



 Comments   
Comment by Sergei Petrunia [ 2019-08-21 ]

Last lines in the .test file before the failing command:

# when alter table happens, it tries to close all other TABLE instances
# when acquiring the exclusive lock for alter table (this happens in SQL layer)
# make sure bulk_load now handles this possible race condition properly
ALTER TABLE t1 ADD INDEX kj(j), ALGORITHM=INPLACE;
 
SELECT COUNT(*) FROM t1 FORCE INDEX(PRIMARY);
SELECT COUNT(*) FROM t1 FORCE INDEX(kj);

Comment by Sergei Petrunia [ 2019-08-21 ]

In August, the issue only happened on winx64-packages, but in July it happened on other (Linux) builders as well.

Comment by Julien Fritsch [ 2023-12-05 ]

Automated message:
----------------------------
Since this issue has not been updated since 6 weeks, it's time to move it back to Stalled.

Comment by JiraAutomate [ 2023-12-05 ]

Automated message:
----------------------------
Since this issue has not been updated since 6 weeks, it's time to move it back to Stalled.

Generated at Thu Feb 08 08:58:58 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.