Merge 10.4 into 10.5

1 files changed, 28 insertions, 28 deletions

diff --git a/sql/rpl_injector.cc b/sql/rpl_injector.cc
index 0726697211b..2319f69d67c 100644
--- a/sql/rpl_injector.cc
+++ b/sql/rpl_injector.cc
@@ -69,34 +69,34 @@ injector::transaction::~transaction()
  */
 int injector::transaction::commit()
 {
-   DBUG_ENTER("injector::transaction::commit()");
-   int error= m_thd->binlog_flush_pending_rows_event(true);
-   /*
-     Cluster replication does not preserve statement or
-     transaction boundaries of the master.  Instead, a new
-     transaction on replication slave is started when a new GCI
-     (global checkpoint identifier) is issued, and is committed
-     when the last event of the check point has been received and
-     processed. This ensures consistency of each cluster in
-     cluster replication, and there is no requirement for stronger
-     consistency: MySQL replication is asynchronous with other
-     engines as well.
-
-     A practical consequence of that is that row level replication
-     stream passed through the injector thread never contains
-     COMMIT events.
-     Here we should preserve the server invariant that there is no
-     outstanding statement transaction when the normal transaction
-     is committed by committing the statement transaction
-     explicitly.
-   */
-   trans_commit_stmt(m_thd);
-   if (!trans_commit(m_thd))
-   {
-     close_thread_tables(m_thd);
-     m_thd->mdl_context.release_transactional_locks();
-   }
-   DBUG_RETURN(error);
+  DBUG_ENTER("injector::transaction::commit()");
+  int error= m_thd->binlog_flush_pending_rows_event(true);
+  /*
+    Cluster replication does not preserve statement or
+    transaction boundaries of the master.  Instead, a new
+    transaction on replication slave is started when a new GCI
+    (global checkpoint identifier) is issued, and is committed
+    when the last event of the check point has been received and
+    processed. This ensures consistency of each cluster in
+    cluster replication, and there is no requirement for stronger
+    consistency: MySQL replication is asynchronous with other
+    engines as well.
+
+    A practical consequence of that is that row level replication
+    stream passed through the injector thread never contains
+    COMMIT events.
+    Here we should preserve the server invariant that there is no
+    outstanding statement transaction when the normal transaction
+    is committed by committing the statement transaction
+    explicitly.
+  */
+  trans_commit_stmt(m_thd);
+  if (!trans_commit(m_thd))
+  {
+    close_thread_tables(m_thd);
+    m_thd->release_transactional_locks();
+  }
+  DBUG_RETURN(error);
 }