Details
-
Bug
-
Status: Closed (View Workflow)
-
Minor
-
Resolution: Won't Fix
-
10.0.2
-
None
-
None
Description
See also MDEV-4468.
SELECT from a federated table pointing at a sequence table crashes the same way as it does with a non-existent table (which is what MDEV-4468 is about)
mysqld: /home/elenst/bzr/10.0/sql/mysqld.cc:3346: void my_message_sql(uint, const char*, myf): Assertion `error != 0' failed.
|
130502 2:01:47 [ERROR] mysqld got signal 6 ;
|
#7 0x00007f2e10c96192 in __GI___assert_fail (assertion=0xe38d1a "error != 0", file=0xe38230 "/home/elenst/bzr/10.0/sql/mysqld.cc", line=3346, function=0xe3f740 "void my_message_sql(uint, const char*, myf)") at assert.c:103
|
#8 0x000000000056a18f in my_message_sql (error=0, str=0x7f2dc7ffd050 "Received error: 0 : ", MyFlags=0) at /home/elenst/bzr/10.0/sql/mysqld.cc:3346
|
#9 0x0000000000dc5808 in my_printf_error (error=0, format=0xf5a8b8 "Received error: %d : %s", MyFlags=0) at /home/elenst/bzr/10.0/mysys/my_error.c:124
|
#10 0x0000000000b34fac in ha_federatedx::info (this=0x7f2ddc00c470, flag=18) at /home/elenst/bzr/10.0/storage/federatedx/ha_federatedx.cc:3089
|
#11 0x00000000007033dd in TABLE_LIST::fetch_number_of_rows (this=0x7f2ddc007110) at /home/elenst/bzr/10.0/sql/table.cc:6765
|
#12 0x000000000065c4dd in make_join_statistics (join=0x7f2ddc010a40, tables_list=..., conds=0x0, keyuse_array=0x7f2ddc010d78) at /home/elenst/bzr/10.0/sql/sql_select.cc:3358
|
#13 0x0000000000655168 in JOIN::optimize_inner (this=0x7f2ddc010a40) at /home/elenst/bzr/10.0/sql/sql_select.cc:1301
|
#14 0x000000000065410e in JOIN::optimize (this=0x7f2ddc010a40) at /home/elenst/bzr/10.0/sql/sql_select.cc:1003
|
#15 0x000000000065bdca in mysql_select (thd=0x2eb66b8, rref_pointer_array=0x2eb9c48, tables=0x7f2ddc007110, wild_num=1, fields=..., conds=0x0, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2147748608, result=0x7f2ddc0109f0, unit=0x2eb92a0, select_lex=0x2eb9998) at /home/elenst/bzr/10.0/sql/sql_select.cc:3215
|
#16 0x000000000065257f in handle_select (thd=0x2eb66b8, lex=0x2eb91e8, result=0x7f2ddc0109f0, setup_tables_done_option=0) at /home/elenst/bzr/10.0/sql/sql_select.cc:371
|
#17 0x0000000000627707 in execute_sqlcom_select (thd=0x2eb66b8, all_tables=0x7f2ddc007110) at /home/elenst/bzr/10.0/sql/sql_parse.cc:5021
|
#18 0x000000000061fd29 in mysql_execute_command (thd=0x2eb66b8) at /home/elenst/bzr/10.0/sql/sql_parse.cc:2482
|
#19 0x0000000000629fc6 in mysql_parse (thd=0x2eb66b8, rawbuf=0x7f2ddc012070 "select * from fed", length=17, parser_state=0x7f2dc7ffe550) at /home/elenst/bzr/10.0/sql/sql_parse.cc:6154
|
#20 0x000000000061cf0e in dispatch_command (command=COM_QUERY, thd=0x2eb66b8, packet=0x2ebaa89 "select * from fed", packet_length=17) at /home/elenst/bzr/10.0/sql/sql_parse.cc:1274
|
#21 0x000000000061c384 in do_command (thd=0x2eb66b8) at /home/elenst/bzr/10.0/sql/sql_parse.cc:983
|
#22 0x0000000000736cc5 in do_handle_one_connection (thd_arg=0x2eb66b8) at /home/elenst/bzr/10.0/sql/sql_connect.cc:1267
|
#23 0x0000000000736a18 in handle_one_connection (arg=0x2eb66b8) at /home/elenst/bzr/10.0/sql/sql_connect.cc:1181
|
#24 0x00007f2e11c7ce9a in start_thread (arg=0x7f2dc7fff700) at pthread_create.c:308
|
#25 0x00007f2e10d5acbd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
|
Test case:
# Run with --sequence and --federated: |
# perl ./mtr --mysqld=--federated --mysqld=--sequence <test name> |
|
|
eval create table fed engine=Federated connection='mysql://root@localhost:$MASTER_MYPORT/test/seq_1_to_2'; |
select * from fed; |
revision-id: knielsen@knielsen-hq.org-20130429100354-0kujsw18axni9syq
|
revno: 3748
|
branch-nick: 10.0
|
Attachments
Issue Links
Activity
I extracted the case about non-existent table into a separate report MDEV-4468, to keep this one a minor issue related to discovery, while the other one is a generic bug with federated tables.
Yes, there's a problem, federated doesn't work with sequence tables.
Because federated uses SHOW TABLE STATUS LIKE to get the information about the remote table (for the local optimizer), and sequence tables, being completely virtual, don't show up in SHOW TABLE STATUS.
While it's not completely impossible to fix, I'd say, it's not worth the troubles and the added complexity.
The failure with non-existing table is also reproducible on 5.5 (and causes a problem on 5.2 and 5.3) So I guess the part related to discovery is that a SEQUENCE table is not discovered through FEDERATED link, and the behaviour is the same as for a non-existent table.