Percona XtraDB Cluster - HA scalable solution for MySQL

rollbacks may leave stale transactional MDL locks

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
Status tracked in Trunk
5.6
Undecided
Unassigned
Trunk
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