Details
Minor
Description
$ perl ./mtr tokudb.type_varchar ... ============================================================================== TEST RESULT TIME (ms) or COMMENT -------------------------------------------------------------------------- worker[1] Using MTR_BUILD_THREAD 300, with reserved ports 16000..16019 tokudb.type_varchar [ pass ] 410 -------------------------------------------------------------------------- The servers were restarted 0 times Spent 0.410 of 7 seconds executing testcases Completed: All 1 tests were successful. elenst@wheezy-64:~/git/5.5/mysql-test$ ls var/mysqld.1/data/ aria_log.00000001 mysql _test_t3_status_1a5_1_1b.tokudb __tokudb_lock_dont_delete_me_environment tokudb.rollback aria_log_control performance_schema tokudb.directory __tokudb_lock_dont_delete_me_logs log000000000000.tokulog27 test tokudb.environment __tokudb_lock_dont_delete_me_recovery mtr _test_t3_main_1a5_2_1b.tokudb __tokudb_lock_dont_delete_me_data __tokudb_lock_dont_delete_me_temp
Any further test that attempts to create t3 (not necessarily of TokuDB engine), fails with 'table already exists').
It's not MariaDB-specific, same happens on Tokutek release binaries of MySQL 5.5.41.
Gliffy Diagrams
Attachments
Issue Links
- relates to
-
MDEV-7069 Fix buildbot failures in main server trees
-
- Stalled
-
- links to
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
DB-830 is fixed. removed an invalid subtest inside of tokudb's type_varchar.test.
Rich Prohaska, I assume this is fixed in tokudb repository, and thus it'll be fixed in MariaDB when we merge.
I'm thus reassigning it to me for merging. Please don't hesitate to reassign back or complain in comments if I misunderstood.
tokudb.type_varchar was cloned from the generic type_varchar test and directed at tokudb. there was a subtest that replaced the frm file for a tokudb table with an old frm file for some other (innodb?) storage engine. this caused the drop table to fail. the bug fix is to remove the invalid subtest.
We never closed it, and rightly so – apparently it was fixed in earlier 5.5 version, but re-appeared now.
==============================================================================
TEST RESULT TIME (ms) or COMMENT
--------------------------------------------------------------------------
worker[1] Using MTR_BUILD_THREAD 300, with reserved ports 16000..16019
tokudb.type_varchar [ pass ] 3730
tokudb_bugs.tokudb718 [ fail ]
Test ended at 2015-09-28 03:33:10
CURRENT_TEST: tokudb_bugs.tokudb718
--- /data/repo/git/5.5/storage/tokudb/mysql-test/tokudb_bugs/r/tokudb718.result 2015-06-06 19:34:09.000000000 +0300
+++ /data/repo/git/5.5/storage/tokudb/mysql-test/tokudb_bugs/r/tokudb718.reject 2015-09-28 03:33:10.000000000 +0300
@@ -6,5 +6,7 @@
select dictionary_name from information_schema.tokudb_fractal_tree_info;
dictionary_name
./test/t-status
+./test/t3-main
+./test/t3-status
commit;
drop table t;
mysqltest: Result length mismatch
TEST RESULT TIME (ms) or COMMENT -------------------------------------------------------------------------- worker[1] Using MTR_BUILD_THREAD 300, with reserved ports 16000..16019 tokudb.type_varchar [ pass ] 4183 -------------------------------------------------------------------------- The servers were restarted 0 times Spent 4.183 of 17 seconds executing testcases Completed: All 1 tests were successful. elenst@wheezy-64:/data/repo/git/5.5/mysql-test$ ls -l var/ install.db/ log/ my.cnf mysqld.1/ plugins/ run/ std_data/ tmp/ elenst@wheezy-64:/data/repo/git/5.5/mysql-test$ ls -l var/mysqld.1/data/ total 884 -rw-rw---- 1 elenst disk 16384 Sep 28 03:34 aria_log.00000001 -rw-rw---- 1 elenst disk 52 Sep 28 03:34 aria_log_control -rw------- 1 elenst disk 750750 Sep 28 03:34 log000000000000.tokulog27 drwxr-xr-x 2 elenst disk 260 Sep 28 03:34 mtr drwxr-xr-x 2 elenst disk 1480 Sep 28 03:34 mysql drwxr-xr-x 2 elenst disk 400 Sep 28 03:34 performance_schema drwxr-xr-x 2 elenst disk 40 Sep 28 03:34 test -rw-rw---- 1 elenst disk 32768 Sep 28 03:34 _test_t3_main_1a5_2_1b.tokudb -rw-rw---- 1 elenst disk 16384 Sep 28 03:34 _test_t3_status_1a5_1_1b.tokudb -rw-rw---- 1 elenst disk 32768 Sep 28 03:34 tokudb.directory -rw-rw---- 1 elenst disk 16384 Sep 28 03:34 tokudb.environment -rw------- 1 elenst disk 0 Sep 28 03:34 __tokudb_lock_dont_delete_me_data -rw------- 1 elenst disk 0 Sep 28 03:34 __tokudb_lock_dont_delete_me_environment -rw------- 1 elenst disk 0 Sep 28 03:34 __tokudb_lock_dont_delete_me_logs -rw------- 1 elenst disk 0 Sep 28 03:34 __tokudb_lock_dont_delete_me_recovery -rw------- 1 elenst disk 0 Sep 28 03:34 __tokudb_lock_dont_delete_me_temp -rw-rw---- 1 elenst disk 32768 Sep 28 03:34 tokudb.rollback
Or maybe it was never fixed... I don't see any difference in tokudb.type_varchar between our 5.5.43 (TokuDB 7.5.6) and 5.5.44 (TokuDB 7.5.7).
And on both versions there are t3 leftovers after tokudb.type_varchar.
But for example this combination, tokudb.type_varchar + tokudb_bugs.tokudb718 , does not reveal the problem on 5.5.43, only 5.5.44, because the query that makes it apparent works differently in these versions, and tokudb_bugs.tokudb718 was modified accordingly: in 5.5.43 the query fails, so no result set is produced, while in 5.5.44 it succeeds, and produces a different result from the expected one.
I've filed a new JIRA report for TokuDB, https://tokutek.atlassian.net/browse/DB-885
Fix is in progress. See https://tokutek.atlassian.net/browse/DB-830.