| Bug #47150 | Assertion in Field_long::val_int() on MERGE + TRIGGER + multi-table UPDATE | ||
|---|---|---|---|
| Submitted: | 5 Sep 2009 11:13 | Modified: | 18 Dec 2009 23:52 |
| Reporter: | Philip Stoev | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: Optimizer | Severity: | S2 (Serious) |
| Version: | 5.1,5.4 | OS: | Any |
| Assigned to: | Sergei Glukhov | CPU Architecture: | Any |
[22 Sep 2009 11:23]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/84104 3124 Sergey Glukhov 2009-09-22 Bug#47150 Assertion in Field_long::val_int() on MERGE + TRIGGER + multi-table UPDATE On PREPARE stage(see test case) we call mark_common_columns() func which creates ON condition for NATURAL JOIN and sets appropriate table read_set bitmaps for fields which are used in ON condition. On EXECUTE stage mark_common_columns() is not called, we set necessary read_set bitmaps in setup_conds(). But 'B.f1' field is already processed and related item alredy fixed before setup_conds() as updated field and setup_conds can not set read_set bitmap because of that. The fix is to set read_set bitmap in Item_direct_view_ref for appropriate field even if the item is fixed. @ mysql-test/r/join.result test result @ mysql-test/t/join.test test case @ sql/item.cc On PREPARE stage(see test case) we call mark_common_columns() func which creates ON condition for NATURAL JOIN and sets appropriate table read_set bitmaps for fields which are used in ON condition. On EXECUTE stage mark_common_columns() is not called, we set necessary read_set bitmaps in setup_conds(). But 'B.f1' field is already processed and related item alredy fixed before setup_conds() as updated field and setup_conds can not set read_set bitmap because of that. The fix is to set read_set bitmap in Item_direct_view_ref for appropriate field even if the item is fixed.
[28 Sep 2009 7:11]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/84789 3124 Sergey Glukhov 2009-09-28 Bug#47150 Assertion in Field_long::val_int() on MERGE + TRIGGER + multi-table UPDATE The bug is not related to MERGE table or TRIGGER. More correct description would be 'assertion on multi-table UPDATE + NATURAL JOIN + MERGEABLE VIEW'. On PREPARE stage(see test case) we call mark_common_columns() func which creates ON condition for NATURAL JOIN and sets appropriate table read_set bitmaps for fields which are used in ON condition. On EXECUTE stage mark_common_columns() is not called, we set necessary read_set bitmaps in setup_conds(). But 'B.f1' field is already processed and related item alredy fixed before setup_conds() as updated field and setup_conds can not set read_set bitmap because of that. The fix is to set read_set bitmap for appropriate table field even if Item_direct_view_ref item which represents a refernce to this field is fixed. @ mysql-test/r/join.result test result @ mysql-test/t/join.test test case @ sql/item.cc The bug is not related to MERGE table or TRIGGER. More correct description would be 'assertion on multi-table UPDATE + NATURAL JOIN + MERGEABLE VIEW'. On PREPARE stage(see test case) we call mark_common_columns() func which creates ON condition for NATURAL JOIN and sets appropriate table read_set bitmaps for fields which are used in ON condition. On EXECUTE stage mark_common_columns() is not called, we set necessary read_set bitmaps in setup_conds(). But 'B.f1' field is already processed and related item alredy fixed before setup_conds() as updated field and setup_conds can not set read_set bitmap because of that. The fix is to set read_set bitmap for appropriate table field even if Item_direct_view_ref item which represents a refernce to this field is fixed.
[28 Sep 2009 13:22]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/84858 3139 Sergey Glukhov 2009-09-28 Bug#47150 Assertion in Field_long::val_int() on MERGE + TRIGGER + multi-table UPDATE The bug is not related to MERGE table or TRIGGER. More correct description would be 'assertion on multi-table UPDATE + NATURAL JOIN + MERGEABLE VIEW'. On PREPARE stage(see test case) we call mark_common_columns() func which creates ON condition for NATURAL JOIN and sets appropriate table read_set bitmaps for fields which are used in ON condition. On EXECUTE stage mark_common_columns() is not called, we set necessary read_set bitmaps in setup_conds(). But 'B.f1' field is already processed and related item alredy fixed before setup_conds() as updated field and setup_conds can not set read_set bitmap because of that. The fix is to set read_set bitmap for appropriate table field even if Item_direct_view_ref item which represents a refernce to this field is fixed. @ mysql-test/r/join.result test result @ mysql-test/t/join.test test case @ sql/item.cc The bug is not related to MERGE table or TRIGGER. More correct description would be 'assertion on multi-table UPDATE + NATURAL JOIN + MERGEABLE VIEW'. On PREPARE stage(see test case) we call mark_common_columns() func which creates ON condition for NATURAL JOIN and sets appropriate table read_set bitmaps for fields which are used in ON condition. On EXECUTE stage mark_common_columns() is not called, we set necessary read_set bitmaps in setup_conds(). But 'B.f1' field is already processed and related item alredy fixed before setup_conds() as updated field and setup_conds can not set read_set bitmap because of that. The fix is to set read_set bitmap for appropriate table field even if Item_direct_view_ref item which represents a refernce to this field is fixed.
[29 Sep 2009 3:23]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/84927 3144 Sergey Glukhov 2009-09-29 Bug#47150 Assertion in Field_long::val_int() on MERGE + TRIGGER + multi-table UPDATE The bug is not related to MERGE table or TRIGGER. More correct description would be 'assertion on multi-table UPDATE + NATURAL JOIN + MERGEABLE VIEW'. On PREPARE stage(see test case) we call mark_common_columns() func which creates ON condition for NATURAL JOIN and sets appropriate table read_set bitmaps for fields which are used in ON condition. On EXECUTE stage mark_common_columns() is not called, we set necessary read_set bitmaps in setup_conds(). But 'B.f1' field is already processed and related item alredy fixed before setup_conds() as updated field and setup_conds can not set read_set bitmap because of that. The fix is to set read_set bitmap for appropriate table field even if Item_direct_view_ref item which represents a refernce to this field is fixed. @ mysql-test/r/join.result test result @ mysql-test/t/join.test test case @ sql/item.cc The bug is not related to MERGE table or TRIGGER. More correct description would be 'assertion on multi-table UPDATE + NATURAL JOIN + MERGEABLE VIEW'. On PREPARE stage(see test case) we call mark_common_columns() func which creates ON condition for NATURAL JOIN and sets appropriate table read_set bitmaps for fields which are used in ON condition. On EXECUTE stage mark_common_columns() is not called, we set necessary read_set bitmaps in setup_conds(). But 'B.f1' field is already processed and related item alredy fixed before setup_conds() as updated field and setup_conds can not set read_set bitmap because of that. The fix is to set read_set bitmap for appropriate table field even if Item_direct_view_ref item which represents a refernce to this field is fixed.
[6 Oct 2009 9:00]
Bugs System
Pushed into 5.1.40 (revid:joro@sun.com-20091006073316-lea2cpijh9r6on7c) (version source revid:sergey.glukhov@sun.com-20090929022338-1t6w2ecpg0j6u1p1) (merge vers: 5.1.40) (pib:11)
[14 Oct 2009 15:37]
Paul DuBois
Noted in 5.1.40 changelog. A multiple-table UPDATE involving a natural join and a mergeable view raised an assertion. Setting report to NDI pending push into 5.5.x+.
[22 Oct 2009 6:35]
Bugs System
Pushed into 6.0.14-alpha (revid:alik@sun.com-20091022063126-l0qzirh9xyhp0bpc) (version source revid:alik@sun.com-20091019135554-s1pvptt6i750lfhv) (merge vers: 6.0.14-alpha) (pib:13)
[22 Oct 2009 7:07]
Bugs System
Pushed into 5.5.0-beta (revid:alik@sun.com-20091022060553-znkmxm0g0gm6ckvw) (version source revid:alik@sun.com-20091013094238-g67x6tgdm9a7uik0) (merge vers: 5.5.0-beta) (pib:13)
[22 Oct 2009 19:42]
Paul DuBois
Noted in 5.5.0, 6.0.14 changelogs.
[18 Dec 2009 10:34]
Bugs System
Pushed into 5.1.41-ndb-7.1.0 (revid:jonas@mysql.com-20091218102229-64tk47xonu3dv6r6) (version source revid:jonas@mysql.com-20091218095730-26gwjidfsdw45dto) (merge vers: 5.1.41-ndb-7.1.0) (pib:15)
[18 Dec 2009 10:49]
Bugs System
Pushed into 5.1.41-ndb-6.2.19 (revid:jonas@mysql.com-20091218100224-vtzr0fahhsuhjsmt) (version source revid:jonas@mysql.com-20091217101452-qwzyaig50w74xmye) (merge vers: 5.1.41-ndb-6.2.19) (pib:15)
[18 Dec 2009 11:05]
Bugs System
Pushed into 5.1.41-ndb-6.3.31 (revid:jonas@mysql.com-20091218100616-75d9tek96o6ob6k0) (version source revid:jonas@mysql.com-20091217154335-290no45qdins5bwo) (merge vers: 5.1.41-ndb-6.3.31) (pib:15)
[18 Dec 2009 11:19]
Bugs System
Pushed into 5.1.41-ndb-7.0.11 (revid:jonas@mysql.com-20091218101303-ga32mrnr15jsa606) (version source revid:jonas@mysql.com-20091218064304-ezreonykd9f4kelk) (merge vers: 5.1.41-ndb-7.0.11) (pib:15)
[10 Sep 2014 6:56]
Roel Van de Paar
Just FYI, this bug is still present in MySQL 5.6.20 2014-09-10 19:47:39 19032 [Note] /sda/mysql-5.6.20-linux-x86_64-debug/bin/mysqld-debug: ready for connections. Version: '5.6.20-debug-log' socket: '/sda/324483/current1_1/tmp/master.sock' port: 13000 MySQL Community Server (GPL) mysqld-debug: /bzr/mysql-5.6/sql/field.cc:3819: virtual longlong Field_long::val_int(): Assertion `!table || (!table->read_set || bitmap_is_set(table->read_set, field_index))' failed. 16:51:04 UTC - mysqld got signal 6 ; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. key_buffer_size=1048576 read_buffer_size=131072 max_used_connections=4 max_threads=151 thread_count=2 connection_count=2 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 61081 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x7fefe3a54000 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... stack_bottom = 7ff01738be20 thread_stack 0x40000 /sda/mysql-5.6.20-linux-x86_64-debug/bin/mysqld-debug(my_print_stacktrace+0x35)[0xa902dc] /sda/mysql-5.6.20-linux-x86_64-debug/bin/mysqld-debug(handle_fatal_signal+0x3f3)[0x7234a3] /lib64/libpthread.so.0(+0xf130)[0x7ff016dd8130] /lib64/libc.so.6(gsignal+0x39)[0x7ff015be1989] /lib64/libc.so.6(abort+0x148)[0x7ff015be3098] /lib64/libc.so.6(+0x2e8f6)[0x7ff015bda8f6] /lib64/libc.so.6(+0x2e9a2)[0x7ff015bda9a2] /sda/mysql-5.6.20-linux-x86_64-debug/bin/mysqld-debug(_ZN10Field_long7val_intEv+0x75)[0x8f727f] /sda/mysql-5.6.20-linux-x86_64-debug/bin/mysqld-debug(_ZN12ha_partition28set_auto_increment_if_higherEP5Field+0x33)[0xe147b5] /sda/mysql-5.6.20-linux-x86_64-debug/bin/mysqld-debug(_ZN12ha_partition10update_rowEPKhPh+0x4dc)[0xe0a1d4] /sda/mysql-5.6.20-linux-x86_64-debug/bin/mysqld-debug(_ZN7handler13ha_update_rowEPKhPh+0x165)[0x6421ab] /sda/mysql-5.6.20-linux-x86_64-debug/bin/mysqld-debug(_Z12mysql_updateP3THDP10TABLE_LISTR4ListI4ItemES6_PS4_jP8st_ordery15enum_duplicatesbPySB_+0x1bf6)[0x85f1fe] /sda/mysql-5.6.20-linux-x86_64-debug/bin/mysqld-debug(_Z21mysql_execute_commandP3THD+0x272a)[0x7d1052] /sda/mysql-5.6.20-linux-x86_64-debug/bin/mysqld-debug(_Z11mysql_parseP3THDPcjP12Parser_state+0x485)[0x7d8fa4] /sda/mysql-5.6.20-linux-x86_64-debug/bin/mysqld-debug(_Z16dispatch_command19enum_server_commandP3THDPcj+0xcbe)[0x7cc557] /sda/mysql-5.6.20-linux-x86_64-debug/bin/mysqld-debug(_Z10do_commandP3THD+0x33e)[0x7cb646] /sda/mysql-5.6.20-linux-x86_64-debug/bin/mysqld-debug(_Z24do_handle_one_connectionP3THD+0x1b6)[0x793a61] /sda/mysql-5.6.20-linux-x86_64-debug/bin/mysqld-debug(handle_one_connection+0x33)[0x79354a] /sda/mysql-5.6.20-linux-x86_64-debug/bin/mysqld-debug(pfs_spawn_thread+0x159)[0xade888] /lib64/libpthread.so.0(+0x7df3)[0x7ff016dd0df3] /lib64/libc.so.6(clone+0x6d)[0x7ff015ca23dd] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (7fefd5c20010): UPDATE `view_table500_innodb_compressed_key_pk_parts_2_int` SET `c21` = 2 WHERE `pk` >= 'b' Connection ID (thread ID): 9 Status: NOT_KILLED
[10 Sep 2014 6:56]
Roel Van de Paar
Maybe a missed code path?
[10 Sep 2014 6:59]
Roel Van de Paar
Maybe different assert. In any case, logged as bug #73869
Description: The following sequence that contains VIEWs, TRIGGERs, MERGE tables and multi-table UPDATE causes mysqld to assert as follows: mysqld: field.cc:3682: virtual longlong Field_long::val_int(): Assertion `!table || (!table->read_set || bitmap_is_set(table->read_set, field_index))' failed. #6 0x000000315a42bec9 in __assert_fail () from /lib64/libc.so.6 #7 0x000000000060cbcc in Field_long::val_int (this=0x1d363b0) at field.cc:3682 #8 0x000000000056b8de in Item_field::val_int (this=0x1d83a20) at item.cc:2029 #9 0x00000000005ae320 in Arg_comparator::compare_int_signed (this=0x1d87540) at item_cmpfunc.cc:1260 #10 0x00000000005be61a in Arg_comparator::compare (this=0x1d87540) at item_cmpfunc.h:71 #11 0x00000000005b2979 in Item_func_eq::val_int (this=0x1d87490) at item_cmpfunc.cc:1645 #12 0x00000000005bcf48 in Item_equal::add (this=0x1d866e8, c=0x1d83a20) at item_cmpfunc.cc:5075 #13 0x00000000005bcfca in Item_equal::update_const (this=0x1d866e8) at item_cmpfunc.cc:5212 #14 0x00000000006d232a in update_const_equal_items (cond=0x1d866e8, tab=0x1d86b38) at sql_select.cc:8200 #15 0x00000000006d228e in update_const_equal_items (cond=0x1d7ff08, tab=0x1d86b38) at sql_select.cc:8193 #16 0x00000000006d27f6 in join_read_const_table (tab=0x1d86b38, pos=0x1d80440) at sql_select.cc:11541 #17 0x00000000006dc148 in make_join_statistics (join=0x1d80380, tables_arg=0x1d81f40, conds=0x1d7ff08, keyuse_array=0x1d81940) at sql_select.cc:2647 #18 0x00000000006de38a in JOIN::optimize (this=0x1d80380) at sql_select.cc:954 #19 0x00000000006e23d3 in mysql_select (thd=0x1cbdd88, rref_pointer_array=0x1d41ee8, tables=0x1d42840, wild_num=0, fields=@0x7f3304eb7760, conds=0x1d7ff08, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=1342177408, result=0x1d802b8, unit=0x1d418f0, select_lex=0x1d41d18) at sql_select.cc:2384 #20 0x000000000070348f in mysql_multi_update (thd=0x1cbdd88, table_list=0x1d42840, fields=0x1d41e20, values=0x1d42200, conds=0x1d7ff08, options=0, handle_duplicates=DUP_ERROR, ignore=false, unit=0x1d418f0, select_lex=0x1d41d18) at sql_update.cc:1228 #21 0x0000000000656d9d in mysql_execute_command (thd=0x1cbdd88) at sql_parse.cc:3090 #22 0x00000000008152df in sp_instr_stmt::exec_core (this=0x1d724d8, thd=0x1cbdd88, nextp=0x7f3304eb8a88) at sp_head.cc:2905 #23 0x0000000000815517 in sp_lex_keeper::reset_lex_and_exec_core (this=0x1d72518, thd=0x1cbdd88, nextp=0x7f3304eb8a88, open_tables=false, instr=0x1d724d8) at sp_head.cc:2734 #24 0x000000000081b6b7 in sp_instr_stmt::execute (this=0x1d724d8, thd=0x1cbdd88, nextp=0x7f3304eb8a88) at sp_head.cc:2848 #25 0x00000000008177ef in sp_head::execute (this=0x1d40fc8, thd=0x1cbdd88) at sp_head.cc:1252 #26 0x0000000000818b19 in sp_head::execute_trigger (this=0x1d40fc8, thd=0x1cbdd88, db_name=0x1d462d8, table_name=0x1d462e8, grant_info=0x1d48cf0) at sp_head.cc:1555 #27 0x0000000000826c47 in Table_triggers_list::process_triggers (this=0x1d48c18, thd=0x1cbdd88, event=TRG_EVENT_INSERT, time_type=TRG_ACTION_AFTER, old_row_is_record1=true) at sql_trigger.cc:2013 #28 0x00000000006ee8bb in write_record (thd=0x1cbdd88, table=0x1d457f8, info=0x1d75be8) at sql_insert.cc:1595 #29 0x00000000006eebfe in select_insert::send_data (this=0x1d75ba8, values=@0x1cbfd18) at sql_insert.cc:3144 #30 0x00000000006bcb7b in end_send (join=0x1d77df8, join_tab=0x1d77570, end_of_records=false) at sql_select.cc:12012 #31 0x00000000006c3aa9 in evaluate_join_record (join=0x1d77df8, join_tab=0x1d77328, error=0) at sql_select.cc:11272 #32 0x00000000006c3cf2 in sub_select (join=0x1d77df8, join_tab=0x1d77328, end_of_records=false) at sql_select.cc:11163 #33 0x00000000006d5277 in do_select (join=0x1d77df8, fields=0x1cbfd18, table=0x0, procedure=0x0) at sql_select.cc:10913 #34 0x00000000006e7687 in JOIN::exec (this=0x1d77df8) at sql_select.cc:2209 #35 0x00000000006e246f in mysql_select (thd=0x1cbdd88, rref_pointer_array=0x1cbfde0, tables=0x1d26c28, wild_num=0, fields=@0x1cbfd18, conds=0x0, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=3492039168, result=0x1d75ba8, unit=0x1cbf7e8, select_lex=0x1cbfc10) at sql_select.cc:2398 #36 0x00000000006e79c7 in handle_select (thd=0x1cbdd88, lex=0x1cbf748, result=0x1d75ba8, setup_tables_done_option=1073741824) at sql_select.cc:268 #37 0x00000000006572e7 in mysql_execute_command (thd=0x1cbdd88) at sql_parse.cc:3193 #38 0x000000000065d3eb in mysql_parse (thd=0x1cbdd88, inBuf=0x1d26078 "REPLACE testdb_A . t1_base_1_A ( `int`,`pk`,`int_key` ) SELECT `int`,`pk`,`int_key` FROM testdb_A . t1_part_2_A AS A", length=122, found_semicolon=0x7f3304ebaed0) at sql_parse.cc:5931 #39 0x000000000065e215 in dispatch_command (command=COM_QUERY, thd=0x1cbdd88, packet=0x1d11e39 "REPLACE testdb_A . t1_base_1_A ( `int`,`pk`,`int_key` ) SELECT `int`,`pk`,`int_key` FROM testdb_A . t1_part_2_A AS A ", packet_length=124) at sql_parse.cc:1213 #40 0x000000000065f5e4 in do_command (thd=0x1cbdd88) at sql_parse.cc:854 #41 0x000000000064bf15 in handle_one_connection (arg=0x1cbdd88) at sql_connect.cc:1127 #42 0x000000315b0073da in start_thread () from /lib64/libpthread.so.0 #43 0x000000315a4e627d in clone () from /lib64/libc.so.6 How to repeat: This test case was automatically culled from a 20K-line query log, so it may still contain redundant items. However, it seems that at least the trigger, the multi-table UPDATE inside the trigger and the MERGE table are all required. CREATE TABLE `table0_int_autoinc` ( `int` int, pk integer auto_increment, `int_key` int, primary key (pk), key (`int_key` )); CREATE TABLE `table1_int_autoinc` ( `int` int, pk integer auto_increment, `int_key` int, primary key (pk), key (`int_key` )); INSERT IGNORE INTO table1_int_autoinc VALUES ('4', NULL, NULL); CREATE TABLE `table10_int_autoinc` ( `int` int, pk integer auto_increment, `int_key` int, primary key (pk), key (`int_key` )); CREATE SCHEMA IF NOT EXISTS testdb_A DEFAULT CHARACTER SET utf8; CREATE TABLE IF NOT EXISTS testdb_A . t1_base_1_A LIKE test . table10_int_autoinc; CREATE TABLE IF NOT EXISTS testdb_A . t1_part_2_A ENGINE = MyISAM PARTITION BY KEY (pk) PARTITIONS 2 AS SELECT `int`,`pk`,`int_key` FROM testdb_A . t1_base_1_A A WHERE `pk` BETWEEN 9 AND 0; CREATE TABLE IF NOT EXISTS testdb_A . t1_base_2_A LIKE test . table1_int_autoinc; CREATE ALGORITHM = MERGE VIEW testdb_A . t1_view_1_A AS SELECT `int`,`pk`,`int_key` FROM testdb_A . t1_base_2_A AS A; CREATE TABLE IF NOT EXISTS testdb_A . t1_temp_2_A LIKE test . table0_int_autoinc; CREATE OR REPLACE ALGORITHM = MERGE VIEW testdb_A . t1_view_2_A AS SELECT `int`,`pk`,`int_key` FROM testdb_A . t1_temp_2_A AS A WHERE `pk` BETWEEN 2 AND 9; INSERT INTO testdb_A . t1_base_1_A SELECT * FROM test . table1_int_autoinc; INSERT INTO testdb_A . t1_base_2_A SELECT * FROM test . table1_int_autoinc; CREATE TABLE IF NOT EXISTS testdb_A . t1_merge_1_A LIKE test . table1_int_autoinc; ALTER TABLE testdb_A . t1_merge_1_A ENGINE = MERGE UNION ( testdb_A . t1_base_1_A , testdb_A . t1_base_2_A ); DELIMITER |; CREATE TRIGGER testdb_A . tr1_2_A AFTER INSERT ON t1_base_1_A FOR EACH ROW BEGIN UPDATE testdb_A . t1_view_2_A AS A NATURAL JOIN testdb_A . t1_view_1_A B SET A. `int_key` = 9, B. `pk` = 1 ; END| DELIMITER ;| INSERT testdb_A . t1_part_2_A ( `int`,`pk`,`int_key` ) SELECT * FROM testdb_A . t1_merge_1_A A; REPLACE testdb_A . t1_base_1_A ( `int`,`pk`,`int_key` ) SELECT `int`,`pk`,`int_key` FROM testdb_A . t1_part_2_A AS A ;