|
This item is specifically about a change in Aria behavior introduced in 10.5 and quoted below, please don't add random diagnostics area failures to it.
It may be that the failure will go away after MDEV-22768 is fixed. The difference is that the failure described here happens even when binary logging is disabled. It didn't happen before the commit shown below.
CREATE TABLE t (a INT) ENGINE=Aria TRANSACTIONAL=1;
|
SET AUTOCOMMIT=OFF;
|
SET STATEMENT binlog_format=mixed FOR INSERT INTO t VALUES (1);
|
COMMIT;
|
|
10.5 620c55e7
|
mariadbd: /data/src/10.5/sql/sql_error.cc:457: void Diagnostics_area::set_error_status(uint, const char*, const char*, const Sql_user_condition_identity&, const Sql_condition*): Assertion `! is_set() || m_can_overwrite_status' failed.
|
220422 18:32:49 [ERROR] mysqld got signal 6 ;
|
|
#7 0x00007fdf080c3662 in __GI___assert_fail (assertion=0x5631e48bbdf8 "! is_set() || m_can_overwrite_status", file=0x5631e48bbb68 "/data/src/10.9/sql/sql_error.cc", line=457, function=0x5631e48bbe20 "void Diagnostics_area::set_error_status(uint, const char*, const char*, const Sql_user_condition_identity&, const Sql_condition*)") at assert.c:101
|
#8 0x00005631e3af4814 in Diagnostics_area::set_error_status (this=0x7fdef0006d18, sql_errno=1679, message=0x7fdf02a85c90 "Cannot modify @@session.binlog_format inside a transaction", sqlstate=0x5631e48ebc4d "HY000", ucid=..., error_condition=0x0) at /data/src/10.9/sql/sql_error.cc:457
|
#9 0x00005631e3ac6103 in THD::raise_condition (this=0x7fdef0000db8, cond=0x7fdf02a85a00) at /data/src/10.9/sql/sql_class.cc:1122
|
#10 0x00005631e39d1501 in THD::raise_condition (this=0x7fdef0000db8, sql_errno=1679, sqlstate=0x5631e4880637 "", level=Sql_state_errno_level::WARN_LEVEL_ERROR, msg=0x7fdf02a85c90 "Cannot modify @@session.binlog_format inside a transaction") at /data/src/10.9/sql/sql_class.h:4822
|
#11 0x00005631e39c0ec2 in my_message_sql (error=1679, str=0x7fdf02a85c90 "Cannot modify @@session.binlog_format inside a transaction", MyFlags=0) at /data/src/10.9/sql/mysqld.cc:3287
|
#12 0x00005631e47852e3 in my_error (nr=1679, MyFlags=0) at /data/src/10.9/mysys/my_error.c:124
|
#13 0x00005631e3d38aff in error_if_in_trans_or_substatement (thd=0x7fdef0000db8, in_substatement_error=1560, in_transaction_error=1679) at /data/src/10.9/sql/sys_vars.cc:581
|
#14 0x00005631e3d38dcd in binlog_format_check (self=0x5631e54bc240 <Sys_binlog_format>, thd=0x7fdef0000db8, var=0x7fdef0043320) at /data/src/10.9/sql/sys_vars.cc:663
|
#15 0x00005631e3a23ede in sys_var::check (this=0x5631e54bc240 <Sys_binlog_format>, thd=0x7fdef0000db8, var=0x7fdef0043320) at /data/src/10.9/sql/set_var.cc:246
|
#16 0x00005631e3a25a2b in set_var::check (this=0x7fdef0043320, thd=0x7fdef0000db8) at /data/src/10.9/sql/set_var.cc:810
|
#17 0x00005631e3a2563e in sql_set_variables (thd=0x7fdef0000db8, var_list=0x7fdef0006108, free=false) at /data/src/10.9/sql/set_var.cc:738
|
#18 0x00005631e3b1c7c6 in LEX::restore_set_statement_var (this=0x7fdef00050f0) at /data/src/10.9/sql/sql_lex.cc:5907
|
#19 0x00005631e3b4b5ca in dispatch_command (command=COM_QUERY, thd=0x7fdef0000db8, packet=0x7fdef000b999 "", packet_length=62, blocking=true) at /data/src/10.9/sql/sql_parse.cc:2484
|
#20 0x00005631e3b48105 in do_command (thd=0x7fdef0000db8, blocking=true) at /data/src/10.9/sql/sql_parse.cc:1407
|
#21 0x00005631e3d1ae92 in do_handle_one_connection (connect=0x5631e7f0f538, put_in_cache=true) at /data/src/10.9/sql/sql_connect.cc:1418
|
#22 0x00005631e3d1ab31 in handle_one_connection (arg=0x5631e7fa8458) at /data/src/10.9/sql/sql_connect.cc:1312
|
#23 0x00005631e4214838 in pfs_spawn_thread (arg=0x5631e7f0f0a8) at /data/src/10.9/storage/perfschema/pfs.cc:2201
|
#24 0x00007fdf0858dea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
|
#25 0x00007fdf0818cdef in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
|
Oddly, on a release build the statement doesn't produce any error or warning, even though in the above stack trace it is clearly trying to set ER_INSIDE_TRANSACTION_PREVENTS_SWITCH_BINLOG_FORMAT, and if we replace SET AUTOCOMMIT=OFF with START TRANSACTION, this error is indeed returned.
The assertion failure started happening on 10.5 after this commit:
commit 4102f1589c23309de968a5bf9511d3228a1b9319
|
Author: Monty
|
Date: Sat May 2 13:19:53 2020 +0300
|
|
Aria will now register it's transactions
|
|
MDEV-22531 Remove maria::implicit_commit()
|
|