MDEV 15532 Assertion `!log->same_pk' failed in row_log_table_apply_delete

The reason for the failure is that
thd->mdl_context.release_transactional_locks()
was called after commit & rollback even in cases where the current
transaction is still active.

For 10.2, 10.3 and 10.4 the fix is simple:
- Replace all calls to thd->mdl_context.release_transactional_locks() with
  thd->release_transactional_locks(). The thd function will only call
  the mdl_context function if there are no active transactional locks.
  In 10.6 we will better fix where we will change the return value for
  some trans_xxx() functions to indicate if transaction did close the
  transaction or not. This will avoid the need of the indirect call.

Other things:
- trans_xa_commit() and trans_xa_rollback() will automatically
  call release_transactional_locks() if the transaction is closed.
- We can't do that for the other functions as the caller of many of these
  are doing additional work (like close_thread_tables) before calling
  release_transactional_locks().
- Added missing abort_result_set() and missing DBUG_RETURN in
  select_create::send_eof()
- Fixed wrong indentation in injector::transaction::commit()

1 files changed, 28 insertions, 28 deletions

diff --git a/sql/rpl_injector.cc b/sql/rpl_injector.cc
index 53999d57bf6..3bcc0204036 100644
--- a/sql/rpl_injector.cc
+++ b/sql/rpl_injector.cc
@@ -68,34 +68,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);
 }