rollbacks may leave stale transactional MDL locks

Bug #1247978 reported by Teemu Ollakka on 2013-11-04
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
MySQL patches by Codership
Status tracked in 5.6
5.5
High
Teemu Ollakka
5.6
High
Teemu Ollakka
Percona XtraDB Cluster moved to https://jira.percona.com/projects/PXC
Status tracked in 5.6
5.5
Fix Released
Undecided
Unassigned
5.6
Fix Released
Undecided
Unassigned

Bug Description

Certain combination of rollbacks may put thd in such a state that it holds transactional MDL locks even if it has no active transaction going on. This becomes apparent by defining Mdl_context::has_transactional_locks() as

  inline bool has_transactional_locks() const
  {
    return !m_tickets[MDL_TRANSACTION].is_empty();
  }

and putting

  DBUG_ASSERT(thd->in_active_multi_stmt_transaction() ||
              thd->in_sub_stmt ||
              !thd->mdl_context.has_transactional_locks());

at the end of mysql_execute_command() function and running randgen generated load with attached grammar. It seems that the reason for this is using thd->in_multi_stmt_transaction_mode() instead of thd->in_active_multi_stmt_transaction() when checking whether to release transactional locks at the end of mysql_execute_command().

Stale locks may cause autocommit selects to cause deadlocks with TOI DDLs when causal reads is on. Thd holding stale lock may be waiting in wsrep_causal_wait() for DDL to be executed while DDL is waiting for MDL lock held by thd waiting in wsrep_causal_wait(). This is not resolved until causal waits times out.

Proposed fix: Force clear of transactional MDL locks whenever there is no active MST at the exit of mysql_execute_command().

This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers