[MDEV-15257] Invalid CREATE INDEX fails to report error correctly Created: 2018-02-09  Updated: 2019-08-29  Resolved: 2019-08-29

Status: Closed
Project: MariaDB Server
Component/s: Data Definition - Alter Table, Storage Engine - InnoDB
Affects Version/s: 10.2, 10.3
Fix Version/s: 10.2.16, 10.3.8

Type: Bug Priority: Major
Reporter: Marko Mäkelä Assignee: Oleksandr Byelkin
Resolution: Fixed Votes: 1
Labels: affects-tests, assertion, ddl, error, regression-10.2


 Description   

The following test is crashing the MariaDB Server 10.2 debug build in the CREATE INDEX:

--source include/have_innodb.inc
 
SET GLOBAL innodb_file_format=Barracuda;
 
SET GLOBAL innodb_large_prefix=0;
 
CREATE TABLE t (a VARCHAR(4000)) ROW_FORMAT=DYNAMIC ENGINE=InnoDB;
 
--error ER_TOO_LONG_KEY
 
CREATE INDEX prefix_idx ON t(a(1000));
 
DROP TABLE t;

The innodb_file_format and ROW_FORMAT=DYNAMIC are defaults. I added them only to test this in 10.0 and 10.1, which rightfully reported the following:

mysqltest: At line 7: query 'CREATE INDEX prefix_idx ON t(a(1000))' succeeded - should have failed with errno 1071...

In 10.2 we instead get the famous debug assertion failure:

mysqld: /mariadb/10.2/sql/sql_error.cc:380: void Diagnostics_area::set_ok_status(ulonglong, ulonglong, const char *): Assertion `!is_set() || (m_status == DA_OK_BULK && is_bulk_op())' failed.

 Comments   
Comment by Marko Mäkelä [ 2018-02-09 ]

The error status is set outside InnoDB, so I think that this needs to be fixed outside InnoDB:

#0  Diagnostics_area::set_error_status (this=0x62a0000ba208, sql_errno=32767, message=0x0, 
    sqlstate=0x0, error_condition=0x7fffdfaefa00) at /mariadb/10.2/sql/sql_error.cc:479
 
#1  0x0000000000906f3a in THD::raise_condition (this=0x62a0000ba208, sql_errno=1071, 
    sqlstate=0x2d81c00 <.str.12> "42000", level=Sql_condition::WARN_LEVEL_ERROR, 
    msg=0x7fffdfaf03e0 "Specified key was too long; max key length is 767 bytes")
 
    at /mariadb/10.2/sql/sql_class.cc:1145
 
#2  0x0000000000974238 in push_warning (thd=0x62a0000ba208, level=Sql_condition::WARN_LEVEL_WARN, 
    code=1071, msg=0x7fffdfaf03e0 "Specified key was too long; max key length is 767 bytes")
 
    at /mariadb/10.2/sql/sql_error.cc:765
 
#3  0x00000000009747a8 in push_warning_printf (thd=0x62a0000ba208, 
    level=Sql_condition::WARN_LEVEL_WARN, code=1071, 
    format=0x63100002b640 "Specified key was too long; max key length is %d bytes")
 
    at /mariadb/10.2/sql/sql_error.cc:800
 
#4  0x0000000000cbbeed in mysql_prepare_create_table (thd=0x62a0000ba208, 
    create_info=0x7fffdfafa010, alter_info=0x7fffdfafa1a0, db_options=0x7fffdfaf3300, file=
 
    0x61c0000538a0, key_info_buffer=0x7fffdfaf7840, key_count=0x7fffdfaf7860, create_table_mode=-2)
 
    at /mariadb/10.2/sql/sql_table.cc:4023
 
#5  0x0000000000cccae4 in mysql_create_frm_image (thd=0x62a0000ba208, db=0x60400000cb70 "test", 
    table_name=0x60400000caf0 "t", create_info=0x7fffdfafa010, alter_info=0x7fffdfafa1a0, 
    create_table_mode=-2, key_info=0x7fffdfaf7840, key_count=0x7fffdfaf7860, frm=0x7fffdfaf7870)
 
    at /mariadb/10.2/sql/sql_table.cc:4652

Comment by Marko Mäkelä [ 2018-02-09 ]

The test is part of an existing test that was inadvertently removed in MariaDB 10.2.2 by the MySQL 5.7.9 merge.
In MySQL 5.7, the MySQL 5.5 test innodb_zip.innodb_prefix_index_liftedlimit was renamed to innodb_zip.prefix_index_liftedlimit. In the above mentioned change, the test was removed, and the regression had an opportunity to emerge in MariaDB Server 10.2.

I will add the test to 10.2, with a reference to this MDEV-15257 in the section that will be commented out until it is re-enabled as part of fixing this regression.

On a related note, the virtual member functions handler::max_supported_key_length() and handler::max_supported_key_part_length() do not allow to accurately represent the limitations of InnoDB. Those limitations depend on the ROW_FORMAT, among other things. In InnoDB, there is a limit on the clustered index record length, and the secondary index records contain PRIMARY KEY values as well.

Comment by Marko Mäkelä [ 2018-02-09 ]

MariaDB Server 10.3 removed the 10.2-deprecated option innodb_large_prefix=0, so the test does not apply as such to 10.3.

Comment by Elena Stepanova [ 2018-05-09 ]

This test does apply to both 10.2 and 10.3 and causes the same effect (still):

--source include/have_innodb.inc
 
CREATE TABLE t1 (b VARCHAR(4096)) ENGINE=InnoDB;
 
--error ER_TOO_LONG_KEY
 
ALTER TABLE t1 ADD KEY(b);
 
 
 
# Cleanup
 
DROP TABLE t1;

10.3 1d30a23fcc38b

 
mysqld: /data/src/10.3/sql/sql_error.cc:335: void Diagnostics_area::set_ok_status(ulonglong, ulonglong, const char*): Assertion `!is_set() || (m_status == DA_OK_BULK && is_bulk_op())' failed.
 
180509  3:08:04 [ERROR] mysqld got signal 6 ;
 
 
 
#7  0x00007f128a3b8ee2 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
 
#8  0x000055ec712715b7 in Diagnostics_area::set_ok_status (this=0x7f1230006050, affected_rows=0, last_insert_id=0, message=0x7f128415c0f0 "Records: 0  Duplicates: 0  Warnings: 1") at /data/src/10.3/sql/sql_error.cc:335
 
#9  0x000055ec7121fe78 in my_ok (thd=0x7f1230000b00, affected_rows_arg=0, id=0, message=0x7f128415c0f0 "Records: 0  Duplicates: 0  Warnings: 1") at /data/src/10.3/sql/sql_class.h:4823
 
#10 0x000055ec71395b6d in mysql_alter_table (thd=0x7f1230000b00, new_db=0x7f1230005170, new_name=0x7f1230005520, create_info=0x7f128415cc60, table_list=0x7f1230014e58, alter_info=0x7f128415cba0, order_num=0, order=0x0, ignore=false) at /data/src/10.3/sql/sql_table.cc:9974
 
#11 0x000055ec7141af26 in Sql_cmd_alter_table::execute (this=0x7f1230015578, thd=0x7f1230000b00) at /data/src/10.3/sql/sql_alter.cc:463
 
#12 0x000055ec712bff63 in mysql_execute_command (thd=0x7f1230000b00) at /data/src/10.3/sql/sql_parse.cc:6283
 
#13 0x000055ec712c4a9a in mysql_parse (thd=0x7f1230000b00, rawbuf=0x7f1230014d78 "ALTER TABLE t1 ADD KEY(b)", length=25, parser_state=0x7f128415e5e0, is_com_multi=false, is_next_command=false) at /data/src/10.3/sql/sql_parse.cc:8003
 
#14 0x000055ec712b219f in dispatch_command (command=COM_QUERY, thd=0x7f1230000b00, packet=0x7f1230125f61 "ALTER TABLE t1 ADD KEY(b)", packet_length=25, is_com_multi=false, is_next_command=false) at /data/src/10.3/sql/sql_parse.cc:1846
 
#15 0x000055ec712b0bc3 in do_command (thd=0x7f1230000b00) at /data/src/10.3/sql/sql_parse.cc:1391
 
#16 0x000055ec714155df in do_handle_one_connection (connect=0x55ec7527c4a0) at /data/src/10.3/sql/sql_connect.cc:1402
 
#17 0x000055ec71415363 in handle_one_connection (arg=0x55ec7527c4a0) at /data/src/10.3/sql/sql_connect.cc:1308
 
#18 0x000055ec718a4471 in pfs_spawn_thread (arg=0x55ec75284920) at /data/src/10.3/storage/perfschema/pfs.cc:1862
 
#19 0x00007f128c08f494 in start_thread (arg=0x7f128415f700) at pthread_create.c:333
 
#20 0x00007f128a47593f in clone () from /lib/x86_64-linux-gnu/libc.so.6

Comment by Elena Stepanova [ 2019-08-29 ]

The problem disappeared from 10.2 after this commit:

commit 6b8802e8dd5467556a024d807a1df23940b00895
 
Author: Oleksandr Byelkin
 
Date:   Tue May 8 15:26:26 2018 +0200
 
 
 
    MDEV-11071: Assertion `thd->transaction.stmt.is_empty()' failed in Locked_tables_list::unlock_locked_table
 
    
    fix_length_and_dec now return result (error/OK)

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