Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.0.1
-
None
-
None
Description
With the following test case
--source include/have_innodb.inc
|
--source include/have_partition.inc
|
|
|
CREATE TABLE t1 ( |
f1 CHAR(1), |
f2 CHAR(1), |
f3 INT, |
KEY(f2), |
KEY(f3) |
) ENGINE=InnoDB
|
PARTITION BY RANGE COLUMNS(f1) ( |
PARTITION p0 VALUES LESS THAN ('m'), |
PARTITION p1 VALUES LESS THAN ('z') |
);
|
INSERT INTO t1 VALUES ('m','j',1); |
INSERT INTO t1 VALUES ('v','m',5); |
|
|
ALTER TABLE t1 ENABLE KEYS; |
|
|
UPDATE t1 SET f2 = 'r' WHERE f3 = 1 AND f2 = 'j' ; |
the last statement causes an error:
query 'UPDATE t1 SET f2 = 'r' WHERE f3 = 1 AND f2 = 'j' ' failed: 1034: Incorrect key file for table 't1'; try to repair it
|
If you allow the test to continue with
CHECK TABLE t1 EXTENDED; |
UPDATE t1 SET f2 = 'r' WHERE f3 = 1 AND f2 = 'j' ; |
it ends with the assertion failure:
InnoDB: Assertion failure in thread 139666781894400 in file row0sel.cc line 2414
|
InnoDB: Failing assertion: field->col->mtype == type
|
#5 0x00007f06c94a6b0b in __GI_abort () at abort.c:92
|
#6 0x0000000000adda7a in row_sel_convert_mysql_key_to_innobase (tuple=0x3186ee8, buf=0x315f800 "\200", buf_len=3136, index=0x31943d8, key_ptr=0x3194c3a "", key_len=6, trx=0x318cd48) at 10.0/storage/innobase/row/row0sel.cc:2414
|
#7 0x0000000000a4a1d9 in ha_innobase::index_read (this=0x315f378, buf=0x318c020 "\363 j\001", key_ptr=0x3194c3a "", key_len=6, find_flag=HA_READ_KEY_EXACT) at 10.0/storage/innobase/handler/ha_innodb.cc:7318
|
#8 0x0000000000a4b04a in ha_innobase::rnd_pos (this=0x315f378, buf=0x318c020 "\363 j\001", pos=0x3194c3a "") at 10.0/storage/innobase/handler/ha_innodb.cc:7797
|
#9 0x0000000000cdafef in ha_partition::rnd_pos (this=0x3191a68, buf=0x318c020 "\363 j\001", pos=0x3194c38 "\001") at 10.0/sql/ha_partition.cc:4341
|
#10 0x00000000007de978 in handler::ha_rnd_pos (this=0x3191a68, buf=0x318c020 "\363 j\001", pos=0x3194c38 "\001") at 10.0/sql/handler.cc:2431
|
#11 0x00000000008f31b2 in QUICK_ROR_INTERSECT_SELECT::get_next (this=0x318bd10) at 10.0/sql/opt_range.cc:10906
|
#12 0x0000000000901f10 in rr_quick (info=0x7f06b4ebd920) at 10.0/sql/records.cc:345
|
#13 0x00000000006d0967 in mysql_update (thd=0x3251c30, table_list=0x32a11a8, fields=..., values=..., conds=0x32a1f88, order_num=0, order=0x0, limit=18446744073709551615, handle_duplicates=DUP_ERROR, ignore=false, found_return=0x7f06b4ebe010, updated_return=0x7f06b4ebe018) at 10.0/sql/sql_update.cc:555
|
#14 0x0000000000615e70 in mysql_execute_command (thd=0x3251c30) at 10.0/sql/sql_parse.cc:3167
|
#15 0x000000000061e4da in mysql_parse (thd=0x3251c30, rawbuf=0x32a1098 "UPDATE t1 SET f2 = 'r' WHERE f3 = 1 AND f2 = 'j'", length=48, parser_state=0x7f06b4ebe4f0) at 10.0/sql/sql_parse.cc:6124
|
#16 0x0000000000611407 in dispatch_command (command=COM_QUERY, thd=0x3251c30, packet=0x31636c1 "UPDATE t1 SET f2 = 'r' WHERE f3 = 1 AND f2 = 'j' ", packet_length=49) at 10.0/sql/sql_parse.cc:1266
|
#17 0x000000000061058e in do_command (thd=0x3251c30) at 10.0/sql/sql_parse.cc:982
|
#18 0x000000000071f773 in do_handle_one_connection (thd_arg=0x3251c30) at 10.0/sql/sql_connect.cc:1267
|
#19 0x000000000071f143 in handle_one_connection (arg=0x3251c30) at 10.0/sql/sql_connect.cc:1181
|
#20 0x0000000000bf326f in pfs_spawn_thread (arg=0x30b3620) at 10.0/storage/perfschema/pfs.cc:1800
|
#21 0x00007f06ca1dfefc in start_thread (arg=0x7f06b4ebf700) at pthread_create.c:304
|
#22 0x00007f06c9551f4d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
|
revision-id: sanja@askmonty.org-20130204153039-ws7tcwfmbi6vil6e
|
revno: 3501
|
branch-nick: maria-10.0
|
Could not reproduce on MariaDB 5.5 or MySQL 5.6.5/5.6.7/5.6.9, so it might be a merge bug.