[MDEV-7863] tokudb.type_varchar leaves dirty datadir (leftovers of t3 table) Created: 2015-03-28  Updated: 2023-11-29  Resolved: 2023-11-29

Status: Closed
Project: MariaDB Server
Component/s: Tests
Affects Version/s: 5.5
Fix Version/s: N/A

Type: Bug Priority: Minor
Reporter: Elena Stepanova Assignee: Sergei Golubchik
Resolution: Won't Fix Votes: 0
Labels: tokudb, upstream

Issue Links:
Relates
relates to MDEV-7069 Fix buildbot failures in main server ... Stalled

 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.

 Comments   
Comment by Rich Prohaska [ 2015-03-29 ]

Fix is in progress. See https://tokutek.atlassian.net/browse/DB-830.

Comment by Rich Prohaska [ 2015-03-30 ]

DB-830 is fixed. removed an invalid subtest inside of tokudb's type_varchar.test.

Comment by Sergei Golubchik [ 2015-03-31 ]

prohaska7, 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.

Comment by Rich Prohaska [ 2015-03-31 ]

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.

Comment by Elena Stepanova [ 2015-09-28 ]

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

Comment by Elena Stepanova [ 2015-09-28 ]

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

Comment by Elena Stepanova [ 2017-07-30 ]

10.x are not affected just because the part of the test that creates t3 is disabled there (goes under if (0)). On 5.5 it is still happening.

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