Bug#19928622: ASSERTION `! IS_SET()' FAILED. | ABORT IN

DIAGNOSTICS_AREA::SET_OK_STATUS

Analysis:
========
When XA transaction is active trying to execute an internal
rollback will result in error ER_XAER_RMFAIL.i.e ERROR 1399
(XAE07): XAER_RMFAIL: The command cannot be executed when
global transaction is in the ACTIVE state. In the bug
scenario a format description BINLOG command is being
executed.

While applying Format_description event there a peace of
code which handles a special scenario. i.e a transaction
NEVER spans on 2 or more binlogs: if we have an active
transaction at this point, the master died while writing
the transaction to the binary log, i.e. while flushing
the binlog cache to the binlog. XA guarantees that master
has rolled back. So we roll back. This rollback fails as
an XA transaction is active and results in error 1399 and
error diagnostic area is set to DA_ERROR. Post execution
of the roll back, code tries to execute my_ok(thd). This
my_ok(thd) expects diagnostic are to be DA_EMPTY since this
contradicts with DA_ERROR an assert is generated.

Fix:
===
The above mentioned rollback scenario should happen only
for real slave when transaction spans across multiple
binlogs. Roll back should not happen if the
Format_description comes through BINLOG command from client.
Hence avoid the call to rollback so that the
Format_description event gets applied successfully.

Author: s.sujatha

mysql-test/suite/binlog/r/binlog_xa_handling.result

@@ -0,0 +1,10 @@
+CREATE TABLE t1(f1 int);
+XA START'','';
+INSERT INTO t1 VALUES(10);
+BINLOG '
+SOgWTg8BAAAAbgAAAHIAAAAAAAQANS42LjMtbTUtZGVidWctbG9nAAAAAAAAAAAAAAAAAAAAAAAA
+AAAAAAAAAAAAAAAAAABI6BZOEzgNAAgAEgAEBAQEEgAAVgAEGggAAAAICAgCAAAAAAVAYI8=';
+XA END'';
+XA PREPARE'';
+XA COMMIT'';
+DROP TABLE t1;

mysql-test/suite/binlog/t/binlog_xa_handling.test

@@ -0,0 +1,22 @@
+###############################################################################
+# Bug#19928622: ASSERTION `! IS_SET()' FAILED. | ABORT IN
+# DIAGNOSTICS_AREA::SET_OK_STATUS
+#
+# Test:
+# =====
+# Begin an XA transaction and execte a DML statement so that XA state becomes
+# XA_ACTIVE. Execute the BINLOG command it should not cause any assert.
+# Execution should be successful.
+###############################################################################
+--source include/have_log_bin.inc
+
+CREATE TABLE t1(f1 int);
+XA START'','';
+INSERT INTO t1 VALUES(10);
+BINLOG '
+SOgWTg8BAAAAbgAAAHIAAAAAAAQANS42LjMtbTUtZGVidWctbG9nAAAAAAAAAAAAAAAAAAAAAAAA
+AAAAAAAAAAAAAAAAAABI6BZOEzgNAAgAEgAEBAQEEgAAVgAEGggAAAAICAgCAAAAAAVAYI8=';
+XA END'';
+XA PREPARE'';
+XA COMMIT'';
+DROP TABLE t1;

sql/log_event.cc

@@ -5734,7 +5734,8 @@ int Format_description_log_event::do_apply_event(Relay_log_info const *rli)
     original place when it comes to us; we'll know this by checking
     log_pos ("artificial" events have log_pos == 0).
   */
-  if (!is_artificial_event() && created && thd->transaction.all.ha_list)
+  if (!thd->rli_fake && !is_artificial_event() && created
+      && thd->transaction.all.ha_list)
   {
     /* This is not an error (XA is safe), just an information */
     rli->report(INFORMATION_LEVEL, 0,