Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
-
10.6, 10.11, 11.1(EOL), 11.2(EOL), 11.4, 11.5(EOL), 11.6(EOL)
Description
INSTALL PLUGIN Spider SONAME 'ha_spider.so'; |
CREATE SERVER srv FOREIGN DATA WRAPPER MYSQL OPTIONS (SOCKET '../socket.sock',DATABASE'',USER'',PASSWORD''); |
CREATE TABLE t1 (c1 TIME) ENGINE=Spider PARTITION BY HASH(EXTRACT(HOUR_SECOND FROM c1)); |
CREATE TABLE t2 (c1 INT) ENGINE=MyISAM; |
CREATE TABLE t3 (c1 INT,c2 INT) ENGINE=Spider COMMENT='WRAPPER "mysql",SRV "srv",TABLE "t1"'; |
INSERT INTO t2 SELECT * FROM t3; |
SELECT * FROM t3; |
ALTER TABLE t1 CHANGE COLUMN c1 d1 INT; |
Leads to:
|
11.2.5 03807c8449cdccbf5b8afc0dddabb1d8ec7ba85a (Debug) |
Core was generated by `/test/MD200724-mariadb-11.2.5-linux-x86_64-dbg/bin/mariadbd --no-defaults --max'.
|
Program terminated with signal SIGSEGV, Segmentation fault.
|
#0 ha_spider::update_create_info (this=0x153fe403ab30, create_info=0x1540280e3630)at /test/11.2_dbg/storage/spider/ha_spider.cc:8610
|
Downloading source file /test/11.2_dbg/storage/spider/ha_spider.cc...
|
[Current thread is 1 (LWP 1347742)]
|
(gdb) bt
|
#0 ha_spider::update_create_info (this=0x153fe403ab30, create_info=0x1540280e3630)at /test/11.2_dbg/storage/spider/ha_spider.cc:8610
|
#1 0x000055e0629d05d8 in ha_partition::update_create_info (this=0x153fe403a250, create_info=<optimized out>)at /test/11.2_dbg/sql/ha_partition.cc:2372
|
#2 0x000055e062504368 in mysql_prepare_alter_table (thd=thd@entry=0x153fe8000d58, table=table@entry=0x153fe40399e8, create_info=create_info@entry=0x1540280e6340, alter_info=alter_info@entry=0x1540280e61d0, alter_ctx=alter_ctx@entry=0x1540280e54b0)at /test/11.2_dbg/sql/sql_table.cc:9237
|
#3 0x000055e062512cec in mysql_alter_table (thd=thd@entry=0x153fe8000d58, new_db=<optimized out>, new_name=new_name@entry=0x153fe8005fd8, create_info=create_info@entry=0x1540280e6340, table_list=<optimized out>, table_list@entry=0x153fe8013738, recreate_info=recreate_info@entry=0x1540280e6190, alter_info=<optimized out>, order_num=<optimized out>, order=<optimized out>, ignore=<optimized out>, if_exists=<optimized out>)at /test/11.2_dbg/sql/sql_table.cc:10878
|
#4 0x000055e06259b609 in Sql_cmd_alter_table::execute (this=<optimized out>, thd=0x153fe8000d58) at /test/11.2_dbg/sql/sql_alter.cc:701
|
#5 0x000055e062425db3 in mysql_execute_command (thd=thd@entry=0x153fe8000d58, is_called_from_prepared_stmt=is_called_from_prepared_stmt@entry=false)at /test/11.2_dbg/sql/sql_parse.cc:5876
|
#6 0x000055e062427753 in mysql_parse (thd=thd@entry=0x153fe8000d58, rawbuf=<optimized out>, length=<optimized out>, parser_state=parser_state@entry=0x1540280e72e0)at /test/11.2_dbg/sql/sql_parse.cc:7920
|
#7 0x000055e062429ada in dispatch_command (command=command@entry=COM_QUERY, thd=thd@entry=0x153fe8000d58, packet=packet@entry=0x153fe800b309 "ALTER TABLE t1 CHANGE COLUMN c1 d1 INT", packet_length=packet_length@entry=38, blocking=blocking@entry=true)at /test/11.2_dbg/sql/sql_class.h:247
|
#8 0x000055e06242bdff in do_command (thd=0x153fe8000d58, blocking=blocking@entry=true) at /test/11.2_dbg/sql/sql_parse.cc:1407
|
#9 0x000055e062592e61 in do_handle_one_connection (connect=<optimized out>, connect@entry=0x55e064df09a8, put_in_cache=put_in_cache@entry=true)at /test/11.2_dbg/sql/sql_connect.cc:1439
|
#10 0x000055e062593156 in handle_one_connection (arg=arg@entry=0x55e064df09a8)at /test/11.2_dbg/sql/sql_connect.cc:1341
|
#11 0x000055e0629e4192 in pfs_spawn_thread (arg=0x55e064dbfb68)at /test/11.2_dbg/storage/perfschema/pfs.cc:2201
|
#12 0x0000154031c97ada in start_thread (arg=<optimized out>)at ./nptl/pthread_create.c:444
|
#13 0x0000154031d2847c in clone3 ()at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78
|
Bug confirmed present in:
MariaDB: 10.6.19 (dbg), 10.6.19 (opt), 10.11.9 (dbg), 10.11.9 (opt), 11.1.6 (dbg), 11.1.6 (opt), 11.2.5 (dbg), 11.2.5 (opt), 11.4.3 (dbg), 11.4.3 (opt), 11.5.2 (dbg), 11.5.2 (opt), 11.6.0 (dbg), 11.6.0 (opt)
Bug (or feature/syntax) confirmed not present in:
MariaDB: 10.5.26 (dbg), 10.5.26 (opt)
Attachments
Issue Links
- duplicates
-
-
- Closed
-
- relates to
-
-
- Closed
-
Activity
Also documenting 10.5 CLI output:
|
10.5.26 b8f92ade57691a78cc97c5d79eae0a27a10cb8f2 (Debug) |
...
|
10.5.26-dbg>INSERT INTO t2 SELECT * FROM t3;
|
ERROR 1136 (21S01): Column count doesn't match value count at row 1
|
10.5.26-dbg>SELECT * FROM t3;
|
ERROR 1429 (HY000): Unable to connect to foreign data source: localhost
|
10.5.26-dbg>ALTER TABLE t1 CHANGE COLUMN c1 d1 INT;
|
ERROR 1486 (HY000): Constant, random or timezone-dependent expressions in (sub)partitioning function are not allowed
|
Hi holyfoot, ptal thanks
eaf360a48b0 upstream/bb-10.5-mdev-34636 MDEV-34636 Spider: reset wide_handler->trx in two occasions
|
a28f4001065 MDEV-34636 Remove implementation of ha-spider::extra() with MERGE flags
|
thanks for the review - pushed the following to 10.5:
42735c557e7 upstream/bb-10.5-mdev-34636 upstream/10.5 MDEV-34636 Spider: reset wide_handler->trx in two occasions
|
f43ea935a12 MDEV-34636 Remove implementation of ha-spider::extra() with MERGE flags
|
This issue actually could be the same problem as the assertion failure in
MDEV-34588. The following is based on 10.6 216fdb155683e960297b089e024c439593bbe6a8.If we remove the implementation of ha_spider::extra() with the MERGE SE specific flags (see the diff block below), we get an assertion failure in spider/bugfix.mdev_29963 and it is the same assertion failure as reported in
MDEV-34588. Upon inspection, it happens at the data node when running LOCK TABLES t2 WRITE;, and the data node query is "lock tables `test`.`t` write".modified storage/spider/ha_spider.cc@@ -1376,7 +1376,6 @@ int ha_spider::reset()int ha_spider::extra(enum ha_extra_function operation) {- int error_num;DBUG_ENTER("ha_spider::extra");DBUG_PRINT("info",("spider this=%p", this));DBUG_PRINT("info",("spider operation=%d", (int) operation));@@ -1428,16 +1427,6 @@ int ha_spider::extra(wide_handler->insert_with_update = TRUE;break;#endif- case HA_EXTRA_ATTACH_CHILDREN:- DBUG_PRINT("info",("spider HA_EXTRA_ATTACH_CHILDREN"));- if (!(wide_handler->trx = spider_get_trx(ha_thd(), TRUE, &error_num)))- DBUG_RETURN(error_num);- break;- case HA_EXTRA_ADD_CHILDREN_LIST:- DBUG_PRINT("info",("spider HA_EXTRA_ADD_CHILDREN_LIST"));- if (!(wide_handler->trx = spider_get_trx(ha_thd(), TRUE, &error_num)))- DBUG_RETURN(error_num);- break;#if defined(HA_EXTRA_HAS_STARTING_ORDERED_INDEX_SCAN) || defined(HA_EXTRA_HAS_HA_EXTRA_USE_CMP_REF)#ifdef HA_EXTRA_HAS_STARTING_ORDERED_INDEX_SCANcase HA_EXTRA_STARTING_ORDERED_INDEX_SCAN:The thd at ha_spider::store_lock is different from that retrieved from spider->wide_handler->trx->thd. Below is the stack trace at the assertion failure:
__GI___assert_fail > thd_get_ha_data > spider_get_trx > spider_check_trx_and_get_conn > ha_spider::append_lock_tables_list > ha_spider::store_lock > get_lock_data > mysql_lock_tables > lock_tables > lock_tables_open_and_lock_tables > mysql_execute_command > ...If we place a breakpoint at ha_spider::extra() and do rc in rr, it is hit in the same query at the data node with a MERGE specific flag. The stack looks like spider was relying on ha_spider::extra() to reset the trx, since ha_spider::open() is not always called from open_table() (called from open_and_process_table()):
ha_spider::extra > open_and_process_table > open_tables > open_tables > lock_tables_open_and_lock_tables > mysql_execute_command > ...The same happens in the
MDEV-34588case. There, the assertion failure happens at the statement LOCK TABLES t2 READ,t1 WRITE.__GI___assert_fail > thd_get_ha_data > spider_get_trx > spider_check_trx_and_get_conn > ha_spider::append_lock_tables_list > ha_spider::store_lock > ha_partition::store_lock > get_lock_data > mysql_lock_tables > lock_tables > lock_tables_open_and_lock_tables > mysql_execute_command > ...However ha_spider::extra() was not called because the
MDEV-33502change mentioned below decided not to call ha_spider::extra() from ha_partition::extra() with the MERGE-specific flag.ha_partition::extra > open_and_process_table > open_tables > open_tables > lock_tables_open_and_lock_tables > mysql_execute_command > ...Note the similarities in the stacks too.