--source include/have_innodb.inc

CREATE TABLE t1 (a INT) ENGINE=InnoDB;

--connect (con1,localhost,root,,test)

FLUSH TABLES WITH READ LOCK;

--connect (con2,localhost,root,,test)

--send

    UPDATE t1 SET a = 1;

--connection default

--send

    CREATE OR REPLACE TABLE t1 (b INT) ENGINE=InnoDB;

--connection con1

CHECK TABLE t1;

# Cleanup

UNLOCK TABLES;

--disconnect con1

--connection con2

--error 0,ER_BAD_FIELD_ERROR

--reap

--disconnect con2

--connection default

--reap

DROP TABLE t1;

mysqld: /data/src/10.4/sql/sql_error.h:1036: uint Diagnostics_area::sql_errno() const: Assertion `m_status == DA_ERROR' failed.

190830 19:38:21 [ERROR] mysqld got signal 6 ;

#7  0x00007f4b0fc4df12 in __GI___assert_fail (assertion=0x5621b78c3b94 "m_status == DA_ERROR", file=0x5621b78c3b00 "/data/src/10.4/sql/sql_error.h", line=1036, function=0x5621b78c46c0 <Diagnostics_area::sql_errno() const::__PRETTY_FUNCTION__> "uint Diagnostics_area::sql_errno() const") at assert.c:101

#8  0x00005621b6bd0c02 in Diagnostics_area::sql_errno (this=0x7f4ab40064c8) at /data/src/10.4/sql/sql_error.h:1036

#9  0x00005621b702af7e in ha_rollback_trans (thd=0x7f4ab4000b00, all=true) at /data/src/10.4/sql/handler.cc:1919

#10 0x00005621b6e759f5 in trans_rollback_implicit (thd=0x7f4ab4000b00) at /data/src/10.4/sql/transaction.cc:387

#11 0x00005621b6e738d8 in mysql_admin_table(THD *, TABLE_LIST *, HA_CHECK_OPT *, const char *, thr_lock_type, bool, bool, uint, int (*)(THD *, TABLE_LIST *, HA_CHECK_OPT *), struct {...}, int (*)(THD *, TABLE_LIST *, HA_CHECK_OPT *)) (thd=0x7f4ab4000b00, tables=0x7f4ab4011e20, check_opt=0x7f4ab4005cd0, operator_name=0x5621b7934851 "check", lock_type=TL_READ_NO_INSERT, org_open_for_modify=false, repair_table_use_frm=false, extra_open_options=32, prepare_func=0x0, operator_func=(int (handler::*)(handler * const, THD *, HA_CHECK_OPT *)) 0x5621b7032488 <handler::ha_check(THD*, st_ha_check_opt*)>, view_operator_func=0x5621b6dfed79 <view_check(THD*, TABLE_LIST*, st_ha_check_opt*)>) at /data/src/10.4/sql/sql_admin.cc:1177

#12 0x00005621b6e741e6 in Sql_cmd_check_table::execute (this=0x7f4ab40124d8, thd=0x7f4ab4000b00) at /data/src/10.4/sql/sql_admin.cc:1352

#13 0x00005621b6cf3ae9 in mysql_execute_command (thd=0x7f4ab4000b00) at /data/src/10.4/sql/sql_parse.cc:6098

#14 0x00005621b6cf8d59 in mysql_parse (thd=0x7f4ab4000b00, rawbuf=0x7f4ab4011d68 "CHECK TABLE t1", length=14, parser_state=0x7f4b08fd3170, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:7908

#15 0x00005621b6ce5002 in dispatch_command (command=COM_QUERY, thd=0x7f4ab4000b00, packet=0x7f4ab4008331 "", packet_length=14, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:1843

#16 0x00005621b6ce3748 in do_command (thd=0x7f4ab4000b00) at /data/src/10.4/sql/sql_parse.cc:1360

#17 0x00005621b6e5d74e in do_handle_one_connection (connect=0x5621b9a24640) at /data/src/10.4/sql/sql_connect.cc:1404

#18 0x00005621b6e5d49d in handle_one_connection (arg=0x5621b9a24640) at /data/src/10.4/sql/sql_connect.cc:1306

#19 0x00005621b778b0ab in pfs_spawn_thread (arg=0x5621b99a3350) at /data/src/10.4/storage/perfschema/pfs.cc:1862

#20 0x00007f4b117c24a4 in start_thread (arg=0x7f4b08fd4700) at pthread_create.c:456

#21 0x00007f4b0fd0ad0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97

diff --git a/sql/handler.cc b/sql/handler.cc

index 57992d98c04..c08c480e9b9 100644

--- a/sql/handler.cc

+++ b/sql/handler.cc

@@ -2203,7 +2203,8 @@ int ha_rollback_trans(THD *thd, bool all)

       Thanks to possibility of MDL deadlock rollback request can come even if

       transaction hasn't been started in any transactional storage engine.

     */

-    if (thd->transaction_rollback_request)

+    if (thd->transaction_rollback_request &&

+        thd->transaction->xid_state.is_explicit_XA())

       thd->transaction->xid_state.set_error(thd->get_stmt_da()->sql_errno());

     thd->has_waiter= false;

Hi Andrei,

many thanks for your work on MDEV-19555.

I am just running automatic test simplification for some Fulltext issue on the development tree

    origin/bb-10.6-MDEV-20605-cur-pos-fix 714b3adc82eac16b46a47c4953cbeedaf14c77cb 2022-01-20T18:41:45+03:00.

The FTS issue I am looking for occurs on actual main trees too.

The corresponding RQG test does neither invoke explicite XA statements nor replication.

DB servers get startet with "--sync-binlog=1".

Before applying your patch to the development tree I got 

    50% of all tests fail because of MDEV-19555    

      1%  fail with the issue I am searching for.

After losing the patience and applying your patch it looks far way better.

It also does not look like the bad effect "Assertion `m_status == DA_ERROR' failed for CHECK TABLE"

is now somehow replaced by some other new bad effect.

The tree

origin/10.8, 10.8 5595ed9d9f20aeb463ac26e075c9cba41927e85e 2022-01-24T19:26:09+09:00

+ MDEV-19555 patch + some preliminary patch for MDEV-14481 performed well in RQG testing

with the test battery for broad range coverage of functionality.

No new bad effects.