Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.0.2
-
None
Description
An attempt to insert a duplicate value into a unique index causes assertion failure on a debug build or unspecified error on a release build.
See also MDEV-4494 – possibly it's a general problem of wrong error handling.
Release build:
MariaDB [test]> insert into t6 values (1);
|
ERROR 1015 (HY000): Can't lock file (errno: 122 "Internal (unspecified) error in handler")
|
Debug build:
10.0/sql/sql_error.cc:422: void Diagnostics_area::set_error_status(THD*, uint, const char*, const char*): Assertion `! is_set() || can_overwrite_status' failed.
|
Cannot index nullable column a
|
130507 22:21:40 [ERROR] mysqld got signal 6 ;
|
#7 0x00007fa34ae8d192 in __GI___assert_fail (assertion=0xe540e0 "! is_set() || can_overwrite_status", file=0xe53fe0 "10.0/sql/sql_error.cc", line=422, function=0xe544a0 "void Diagnostics_area::set_error_status(THD*, uint, const char*, const char*)") at assert.c:103
|
#8 0x00000000005fa9b2 in Diagnostics_area::set_error_status (this=0x24feb50, thd=0x24faad8, sql_errno_arg=1015, message_arg=0x7fa33a5298f0 "Can't lock file (errno: 122 \"Internal (unspecified) error in handler\")", sqlstate=0xe694b9 "HY000") at 10.0/sql/sql_error.cc:422
|
#9 0x00000000005e3371 in THD::raise_condition (this=0x24faad8, sql_errno=1015, sqlstate=0xe694b9 "HY000", level=MYSQL_ERROR::WARN_LEVEL_ERROR, msg=0x7fa33a5298f0 "Can't lock file (errno: 122 \"Internal (unspecified) error in handler\")") at 10.0/sql/sql_class.cc:1206
|
#10 0x000000000056a23d in my_message_sql (error=1015, str=0x7fa33a5298f0 "Can't lock file (errno: 122 \"Internal (unspecified) error in handler\")", MyFlags=0) at 10.0/sql/mysqld.cc:3369
|
#11 0x0000000000dc5680 in my_error (nr=1015, MyFlags=0) at 10.0/mysys/my_error.c:96
|
#12 0x00000000008da20e in print_lock_error (error=122, table=0x7fa32c01e718) at 10.0/sql/lock.cc:921
|
#13 0x00000000008d985b in unlock_external (thd=0x24faad8, table=0x7fa32c009b10, count=1) at 10.0/sql/lock.cc:674
|
#14 0x00000000008d8da7 in mysql_unlock_tables (thd=0x24faad8, sql_lock=0x7fa32c009ae8, free_lock=true) at 10.0/sql/lock.cc:382
|
#15 0x00000000005bcd04 in close_thread_tables (thd=0x24faad8) at 10.0/sql/sql_base.cc:1545
|
#16 0x0000000000627196 in mysql_execute_command (thd=0x24faad8) at 10.0/sql/sql_parse.cc:4921
|
#17 0x0000000000629fc6 in mysql_parse (thd=0x24faad8, rawbuf=0x7fa32c118c30 "INSERT INTO t1 VALUES (1),(1)", length=29, parser_state=0x7fa33a52a500) at 10.0/sql/sql_parse.cc:6154
|
#18 0x000000000061cf0e in dispatch_command (command=COM_QUERY, thd=0x24faad8, packet=0x24feea9 "INSERT INTO t1 VALUES (1),(1)", packet_length=29) at 10.0/sql/sql_parse.cc:1274
|
#19 0x000000000061c384 in do_command (thd=0x24faad8) at 10.0/sql/sql_parse.cc:983
|
#20 0x0000000000736cc5 in do_handle_one_connection (thd_arg=0x24faad8) at 10.0/sql/sql_connect.cc:1267
|
#21 0x0000000000736a18 in handle_one_connection (arg=0x24faad8) at 10.0/sql/sql_connect.cc:1181
|
#22 0x00000000009c9893 in pfs_spawn_thread (arg=0x236f848) at 10.0/storage/perfschema/pfs.cc:1800
|
#23 0x00007fa34be73e9a in start_thread (arg=0x7fa33a52b700) at pthread_create.c:308
|
#24 0x00007fa34af51cbd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
|
Test case:
CREATE TABLE t1 (a INT, UNIQUE INDEX(a)) ENGINE=CONNECT; |
INSERT INTO t1 VALUES (1),(1); |
bzr version-info
revision-id: knielsen@knielsen-hq.org-20130429100354-0kujsw18axni9syq
|
revno: 3748
|
branch-nick: 10.0
|
Attachments
Activity
A proper error message is now generated. However, in debug mode, it is sent as a warning to avoid MariaDB stopping the server.
Note that the insert or update is done (CONNECT does not roll back) but the index is not constructed.
The crash happens because the server doesn't expect external_lock(F_UNLCK) to fail.
It's not quite clear where we want to allow it to fail, the semantics of that failure is confusing. Was the table unlocked, despite the error? Were the changes rolled back?
If we won't allow that, we'd need some other way for an engine to support deferred constraint checking (currently CONNECT is doing it in external_lock)).