Details
-
Bug
-
Status: Closed (View Workflow)
-
Minor
-
Resolution: Fixed
-
5.5.36, 10.0.10
-
None
-
None
Description
I set it to minor, because the pre-conditions don't seem to be common: disabled InnoDB plus installing TokuDB at runtime.
MTR test case:
--source include/have_log_bin.inc
|
|
|
INSTALL SONAME 'ha_tokudb'; |
DROP TABLE IF EXISTS t1; |
CREATE TABLE t1 (a INT) ENGINE=TokuDB; |
INSERT INTO t1 VALUES (1),(2); |
The same SQL causes the failure without MTR, too, but make sure that the server is started with
--log-bin --skip-innodb --default-storage-engine=MyISAM
|
and it does not have TokuDB installed yet.
5.5/sql/log.h:97: virtual int TC_LOG_DUMMY::log_and_order(THD*, my_xid, bool, bool, bool): Assertion `0' failed.
|
140412 19:34:32 [ERROR] mysqld got signal 6 ;
|
#6 0x00007fe702e42621 in *__GI___assert_fail (assertion=0xe4a427 "0", file=<optimized out>, line=97, function=0xe4d7e0 "virtual int TC_LOG_DUMMY::log_and_order(THD*, my_xid, bool, bool, bool)") at assert.c:81
|
#7 0x00000000008b5c49 in TC_LOG_DUMMY::log_and_order (this=0x15a0798, thd=0x7fe701749060, xid=24, all=false, need_prepare_ordered=false, need_commit_ordered=false) at 5.5/sql/log.h:97
|
#8 0x00000000007e4fcf in ha_commit_trans (thd=0x7fe701749060, all=false) at 5.5/sql/handler.cc:1312
|
#9 0x0000000000740464 in trans_commit_stmt (thd=0x7fe701749060) at 5.5/sql/transaction.cc:345
|
#10 0x0000000000637ebe in mysql_execute_command (thd=0x7fe701749060) at 5.5/sql/sql_parse.cc:4573
|
#11 0x000000000063ab54 in mysql_parse (thd=0x7fe701749060, rawbuf=0x7fe6fd948078 "INSERT INTO t1 VALUES (1),(2)", length=29, parser_state=0x7fe6fe3b5630) at 5.5/sql/sql_parse.cc:5800
|
#12 0x000000000062eb75 in dispatch_command (command=COM_QUERY, thd=0x7fe701749060, packet=0x7fe6feb00061 "INSERT INTO t1 VALUES (1),(2)", packet_length=29) at 5.5/sql/sql_parse.cc:1079
|
#13 0x000000000062dd01 in do_command (thd=0x7fe701749060) at 5.5/sql/sql_parse.cc:793
|
#14 0x000000000072f1aa in do_handle_one_connection (thd_arg=0x7fe701749060) at 5.5/sql/sql_connect.cc:1266
|
#15 0x000000000072ec69 in handle_one_connection (arg=0x7fe701749060) at 5.5/sql/sql_connect.cc:1181
|
#16 0x0000000000b61755 in pfs_spawn_thread (arg=0x7fe6feb8dac0) at 5.5/storage/perfschema/pfs.cc:1015
|
#17 0x00007fe7043a2b50 in start_thread (arg=<optimized out>) at pthread_create.c:304
|
#18 0x00007fe702ef1a7d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
|
Stack trace from:
revision-id: knielsen@knielsen-hq.org-20140411084611-oygkym1990hgbuhe
|
date: 2014-04-11 10:46:11 +0200
|
build-date: 2014-04-12 19:42:26 +0400
|
revno: 4133
|
branch-nick: 5.5
|
Attachments
Issue Links
- is duplicated by
-
-
- Closed
-
Activity
As a fix I'll disable XA in the loaded engine (with a warning). Trying to switch tc_log implementation run-time may be too risky for this uncommon scenario.
TC_LOG_DUMMY is used if the number of XA storage engines is <= 1 when mysqld initializes. If an XA storage engine is installed later one, there is no code to redo the initialization of the logs. One currently must restart mysqld instead.