Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.1(EOL)
Description
Note: it's possible that the problem is not specific to the optimistic parallel slave, but I'm only getting it with this mode. It might be even not related to the replication at all, for that matter – in this case please reassign it to whoever you think it fits best, or back to me.
sql/field.cc:3837: virtual longlong Field_long::val_int(): Assertion `!table || table->in_use == _current_thd()' failed.
|
150408 17:00:53 [ERROR] mysqld got signal 6 ;
|
|
Stack trace from 10.1 commit 7ee1a41c |
#6 0x00007f930e94f311 in *__GI___assert_fail (assertion=0x7f9311c969e8 "!table || table->in_use == _current_thd()", file=<optimized out>, line=3837, function=0x7f9311c9a560 "virtual longlong Field_long::val_int()") at assert.c:81
|
#7 0x00007f9311482014 in Field_long::val_int (this=0x7f92fb210c88) at sql/field.cc:3837
|
#8 0x00007f931165ce2f in ha_innobase::write_row (this=0x7f92fb250088, record=0x7f92e401d588 "\035#\377)\350", <incomplete sequence \366>) at storage/xtradb/handler/ha_innodb.cc:8326
|
#9 0x00007f93114b4a5e in handler::ha_write_row (this=0x7f92fb250088, buf=0x7f92e401d588 "\035#\377)\350", <incomplete sequence \366>) at sql/handler.cc:5865
|
#10 0x00007f931125c709 in write_record (thd=0x7f92e355b070, table=0x7f92e27cb070, info=0x7f92e3596060) at sql/sql_insert.cc:1854
|
#11 0x00007f931126122a in select_insert::send_data (this=0x7f92e3596020, values=...) at sql/sql_insert.cc:3617
|
#12 0x00007f93112e4a9f in end_send (join=0x7f92e35960c0, join_tab=0x7f92e3668cb0, end_of_records=false) at sql/sql_select.cc:19017
|
#13 0x00007f93112e2884 in evaluate_join_record (join=0x7f92e35960c0, join_tab=0x7f92e3668968, error=0) at sql/sql_select.cc:18121
|
#14 0x00007f93112e214f in sub_select (join=0x7f92e35960c0, join_tab=0x7f92e3668968, end_of_records=false) at sql/sql_select.cc:17896
|
#15 0x00007f93112e198e in do_select (join=0x7f92e35960c0, fields=0x7f92e355f5f8, table=0x0, procedure=0x0) at sql/sql_select.cc:17553
|
#16 0x00007f93112bd11a in JOIN::exec_inner (this=0x7f92e35960c0) at sql/sql_select.cc:3096
|
#17 0x00007f93112ba3f5 in JOIN::exec (this=0x7f92e35960c0) at sql/sql_select.cc:2396
|
#18 0x00007f93112bd9b8 in mysql_select (thd=0x7f92e355b070, rref_pointer_array=0x7f92e355f758, tables=0x7f92e3595990, wild_num=1, fields=..., conds=0x0, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=3524266752, result=0x7f92e3596020, unit=0x7f92e355edf0, select_lex=0x7f92e355f4e0) at sql/sql_select.cc:3324
|
#19 0x00007f93112b3ab5 in handle_select (thd=0x7f92e355b070, lex=0x7f92e355ed28, result=0x7f92e3596020, setup_tables_done_option=1073741824) at sql/sql_select.cc:373
|
#20 0x00007f931127df86 in mysql_execute_command (thd=0x7f92e355b070) at sql/sql_parse.cc:3948
|
#21 0x00007f931128827a in mysql_parse (thd=0x7f92e355b070, rawbuf=0x7f92e2c8b579 "INSERT INTO `create_or_replace_tmp` SELECT * FROM `table0_innodb_key_pk_parts_2_int_autoinc`", length=92, parser_state=0x7f930d722a60) at sql/sql_parse.cc:7165
|
#22 0x00007f931159d400 in Query_log_event::do_apply_event (this=0x7f92e2d0f870, rgi=0x7f92e2cf6800, query_arg=0x7f92e2c8b579 "INSERT INTO `create_or_replace_tmp` SELECT * FROM `table0_innodb_key_pk_parts_2_int_autoinc`", q_len_arg=92) at sql/log_event.cc:4287
|
#23 0x00007f931159c685 in Query_log_event::do_apply_event (this=0x7f92e2d0f870, rgi=0x7f92e2cf6800) at sql/log_event.cc:4013
|
#24 0x00007f93111e5f64 in Log_event::apply_event (this=0x7f92e2d0f870, rgi=0x7f92e2cf6800) at sql/log_event.h:1347
|
#25 0x00007f93111dbac0 in apply_event_and_update_pos (ev=0x7f92e2d0f870, thd=0x7f92e355b070, rgi=0x7f92e2cf6800, rpt=0x7f92fc0906d0) at sql/slave.cc:3257
|
#26 0x00007f931141100b in rpt_handle_event (qev=0x7f92e2d2c470, rpt=0x7f92fc0906d0) at sql/rpl_parallel.cc:48
|
#27 0x00007f931141309c in handle_rpl_parallel_thread (arg=0x7f92fc0906d0) at sql/rpl_parallel.cc:891
|
#28 0x00007f931096ab50 in start_thread (arg=<optimized out>) at pthread_create.c:304
|
#29 0x00007f930e9ff95d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
|
To reproduce, I start the master server with
--server-id=1 --log-bin=mysql-bin
|
otherwise all defaults, with the attached binlog files.
Slave runs with
--slave-parallel-mode=optimistic --slave-parallel-threads=20 --port=3307 --server_id=2
|
On the slave, I run
CHANGE MASTER TO MASTER_PORT = 3306, MASTER_HOST = '127.0.0.1', MASTER_USER = 'root'; |
START SLAVE;
|
and wait. Usually it crashes after a while (not every time though).
Attachments
Activity
http://lists.askmonty.org/pipermail/commits/2015-April/007743.html
http://lists.askmonty.org/pipermail/commits/2015-April/007744.html
The problem is with temporary tables in statement-based replication.
In the supplied test case, two transactions are run in parallel that access
the same temporary table, and this is not handled correctly in the code.
MDEV-7668tried to fix this, by making any use of temptables in parallelreplication wait for prior transactions to commit. But the fix was
insufficient, apparently it did not add a wait to find_temporary_table().
However, even such wait is not sufficient. Because user may binlog two
transactions in distinct replication domains that access the same temporary
table. This would be user error, and replication can be allowed to break,
but the server should not crash, which seems likely to happen in current
code where there is no protection against a temporary table being accessed
simultaneously by multiple worker threads.