[MDEV-17573] Assertion in federatedx on multi-update Created: 2018-10-30  Updated: 2020-12-09  Resolved: 2020-12-09

Status: Closed
Project: MariaDB Server
Component/s: Storage Engine - Federated
Affects Version/s: 10.2, 10.3, 10.4, 10.5
Fix Version/s: 10.2.37, 10.3.28, 10.4.18, 10.5.9

Type: Bug Priority: Major
Reporter: Aleksey Midenkov Assignee: Aleksey Midenkov
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Relates
relates to MDEV-14551 Can't find record in table on multi-t... Closed
relates to MDEV-16937 Strict SQL with system versioned tabl... Closed

 Description   

Reproduce

--source have_federatedx.inc
create or replace table t1 (
  x int,
  d timestamp(6));
--replace_result $MASTER_MYPORT MASTER_MYPORT
eval create or replace table tf engine=FEDERATED connection='mysql://root@127.0.0.1:$MASTER_MYPORT/test/t1';
 
create or replace table t2 (
  x int, y int,
  d timestamp(6));
--replace_result $MASTER_MYPORT MASTER_MYPORT
eval create or replace table t2f engine=FEDERATED connection='mysql://root@127.0.0.1:$MASTER_MYPORT/test/t2';
 
create or replace table t3 (
  x int, y int, z int,
  d timestamp(6));
--replace_result $MASTER_MYPORT MASTER_MYPORT
eval create or replace table t3f engine=FEDERATED connection='mysql://root@127.0.0.1:$MASTER_MYPORT/test/t3';
 
 
insert into t1 values (1, "1990-01-01 00:00");
insert into t1 values (1, "1991-01-01 11:11");
insert into t2 values (2, 2, "1992-02-02 22:22");
insert into t3 values (3, 3, 3, "1993-03-03 23:33");
update tf, t2f, t3f set tf.x= 11, t2f.y= 22, t3f.z= 33;
 
drop database test;
create database test;

Result

#3  0x00007ffff6d16142 in __GI___assert_fail (assertion=0x146668d "len < 0xFFFFFFFFL", file=0x1464f50 "/home/midenok/src/mariadb/trunk/src/sql/sql_error.h", line=841, function=0x146669f "virtual const char *ErrConvString::ptr() const") at assert.c:101
#4  0x000000000065683d in ErrConvString::ptr (this=0x7ffff0ae4378) at /home/midenok/src/mariadb/trunk/src/sql/sql_error.h:841
#5  0x0000000000a835dd in Field_num::check_edom_and_important_data_truncation (this=0x7fffe0043cf0, type=0x15aa6d0 "integer", edom=true, cs=0x1d66dc0 <my_charset_bin>, str=0x7fffe0066fcd "\217\217\217", length=3543410658499006563, end=0x7fffe0066fcd "\217\217\217") at /home/midenok/src/mariadb/trunk/src/sql/field.cc:1530
#6  0x0000000000a83837 in Field_num::check_edom_and_truncation (this=0x7fffe0043cf0, type=0x15aa6d0 "integer", edom=true, cs=0x1d66dc0 <my_charset_bin>, str=0x7fffe0066fcd "\217\217\217", length=3543410658499006563, end=0x7fffe0066fcd "\217\217\217") at /home/midenok/src/mariadb/trunk/src/sql/field.cc:1548
#7  0x0000000000ab11ed in Field_num::check_int (this=0x7fffe0043cf0, cs=0x1d66dc0 <my_charset_bin>, str=0x7fffe0066fcd "\217\217\217", length=3543410658499006563, int_end=0x7fffe0066fcd "\217\217\217", error=33) at /home/midenok/src/mariadb/trunk/src/sql/field.h:1657
#8  0x0000000000a839d4 in Field_num::get_int (this=0x7fffe0043cf0, cs=0x1d66dc0 <my_charset_bin>, from=0x7fffe0066fcd "\217\217\217", len=3543410658499006563, rnd=0x7ffff0ae4798, unsigned_max=4294967295, signed_min=-2147483648, signed_max=2147483647) at /home/midenok/src/mariadb/trunk/src/sql/field.cc:1613
#9  0x0000000000a8f3e0 in Field_long::store (this=0x7fffe0043cf0, from=0x7fffe0066fcd "\217\217\217", len=3543410658499006563, cs=0x1d66dc0 <my_charset_bin>) at /home/midenok/src/mariadb/trunk/src/sql/field.cc:4145
#10 0x00007ffff1df721a in ha_federatedx::convert_row_to_internal_format (this=0x7fffe0043ec0, record=0x7fffe0043ad8 "\361\001", row=0x7fffe0066f98, result=0x7fffe0060f98) at /home/midenok/src/mariadb/trunk/src/storage/federatedx/ha_federatedx.cc:888
#11 0x00007ffff1dfdf25 in ha_federatedx::read_next (this=0x7fffe0043ec0, buf=0x7fffe0043ad8 "\361\001", result=0x7fffe0060f98) at /home/midenok/src/mariadb/trunk/src/storage/federatedx/ha_federatedx.cc:2943
#12 0x00007ffff1dfeeec in ha_federatedx::rnd_pos (this=0x7fffe0043ec0, buf=0x7fffe0043ad8 "\361\001", pos=0x7fffe005bed1 "\230\017\006\340\377\177") at /home/midenok/src/mariadb/trunk/src/storage/federatedx/ha_federatedx.cc:3016
#13 0x0000000000acde7e in handler::ha_rnd_pos (this=0x7fffe0043ec0, buf=0x7fffe0043ad8 "\361\001", pos=0x7fffe005bed1 "\230\017\006\340\377\177") at /home/midenok/src/mariadb/trunk/src/sql/handler.cc:2798
#14 0x00000000008b07e6 in multi_update::do_updates (this=0x7fffe0017960) at /home/midenok/src/mariadb/trunk/src/sql/sql_update.cc:2642
#15 0x00000000008b119e in multi_update::send_eof (this=0x7fffe0017960) at /home/midenok/src/mariadb/trunk/src/sql/sql_update.cc:2807
#16 0x00000000007f7d41 in do_select (join=0x7fffe0017a38, procedure=0x0) at /home/midenok/src/mariadb/trunk/src/sql/sql_select.cc:18898
#17 0x00000000007f6879 in JOIN::exec_inner (this=0x7fffe0017a38) at /home/midenok/src/mariadb/trunk/src/sql/sql_select.cc:4035
#18 0x00000000007f598e in JOIN::exec (this=0x7fffe0017a38) at /home/midenok/src/mariadb/trunk/src/sql/sql_select.cc:3829
#19 0x00000000007cdad7 in mysql_select (thd=0x7fffe0000cf8, tables=0x7fffe0015f98, wild_num=0, fields=..., conds=0x0, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=1342177408, result=0x7fffe0017960, unit=0x7fffe0004ba8, select_lex=0x7fffe0005318) at /home/midenok/src/mariadb/trunk/src/sql/sql_select.cc:4234
#20 0x00000000008acd57 in mysql_multi_update (thd=0x7fffe0000cf8, table_list=0x7fffe0015f98, fields=0x7fffe0005440, values=0x7fffe0005948, conds=0x0, options=0, handle_duplicates=DUP_ERROR, ignore=false, unit=0x7fffe0004ba8, select_lex=0x7fffe0005318, result=0x7ffff0ae6f78) at /home/midenok/src/mariadb/trunk/src/sql/sql_update.cc:1758
#21 0x00000000007875dd in mysql_execute_command (thd=0x7fffe0000cf8) at /home/midenok/src/mariadb/trunk/src/sql/sql_parse.cc:4640
#22 0x000000000077f640 in mysql_parse (thd=0x7fffe0000cf8, rawbuf=0x7fffe0015e80 "update tf, t2f, t3f set tf.x= 11, t2f.y= 22, t3f.z= 33", length=54, parser_state=0x7ffff0ae85e0, is_com_multi=false, is_next_command=false) at /home/midenok/src/mariadb/trunk/src/sql/sql_parse.cc:8091



 Comments   
Comment by Aleksey Midenkov [ 2018-10-30 ]

Analysis

Comment by Aleksey Midenkov [ 2018-10-31 ]

Cause

Shared federatedx_io cannot store table-specific data.

Fix

Move current row reference (federatedx_io_mysql::current) to ha_federatedx.

Testing...

Comment by Sergei Golubchik [ 2019-10-29 ]

I don't quite understand. How is federatedx_io shared? Between what and what?

Comment by Sergei Golubchik [ 2020-10-19 ]

what's the state of it?

Comment by Aleksey Midenkov [ 2020-10-21 ]

FederatedX connection (represented by federatedx_io) is stored into federatedx_txn::txn_list of per-server connections (see federatedx_txn::acquire()). federatedx_txn object is stored into THD (see ha_federatedx::external_lock()). When multiple handlers acquire FederatedX connection they get one federatedx_io instance. Multiple handlers do their operation via federatedx_io_mysql::mark_position() and federatedx_io_mysql::fetch_row() in arbitrarty manner. They access the same federatedx_io_mysql instance and same MYSQL_ROWS *current pointer, so one handler disrupts the work of the other.

Updated commit message. Please review caec6b4b

Comment by Aleksey Midenkov [ 2020-10-21 ]

Please instruct if refactoring required regarding federatedx_io::mark_position() / fetch_row().

Comment by Sergei Golubchik [ 2020-10-23 ]

I think your patch is enough.
FederatedX code can be improved, but there's no need to do it in 10.3

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