Created by Laurynas Biveinis and last modified
Get this branch:
bzr branch lp:~laurynas-biveinis/percona-server/bug1404565
Only Laurynas Biveinis can upload to this branch. If you are Laurynas Biveinis please log in for upload directions.

Branch merges

Related bugs

Related blueprints

Branch information

Recent revisions

720. By Laurynas Biveinis


The bug is caused by a merge regression in the initial 5.6 port:
XtraDB moves the transaction section to the end of status output, but
the merge failed to remove it from its original location.

The patch to move the transaction section to the end of status output
originates from Google patches for 5.0.37. The purpose of the patch is
to provide useful InnoDB status output in the case of very long
transaction list that would not fit into 64KB that is the maximum
possible result set length in that version. Since then, the maximum
status output limit has been raised to 1MB
(http://bugs.mysql.com/bug.php?id=56922). Given this and that we
haven't received any truncated status issue reports while we were
printing the transaction list even twice in the output, remove the
Google patch bit and leave the transaction list in its upstream

718. By Alexey Kopytov

Bug #1405076: Deadlock in RELEASE_LOCK()

The RELEASE_LOCK() implementation introduced by the multiple user level
locks patch can result in a deadlock under the following conditions:

- connection #1 calls RELEASE_LOCK() for a previously acquired lock. In
  which case MDL_lock::remove_ticket() is called, which write-locks
  MDL_lock::m_rwlock corresponding to the user-level MDL object. With
  that lock held, MDL_map_partition::remove() is called which locks
  MDL_map_partition::m_mutex protecting the hash of MDL locks belonging
  to an MDL partition.

- connection #2 calls RELEASE_LOCK() simultaneously for the same lock
  being released by connection #1. Since connection #2 did not own the
  lock, it calls MDL_map_partition::get_lock_owner() to check if 0 or
  NULL should be returned (i.e. if the lock exists). That function also
  locks both MDL_map_partition::m_mutex and MDL_lock::m_rwlock(), but in
  the reverse order as compared to connection #1.

With the right timing for the above events we get each thread waiting
for a lock acquired by the other thread, i.e. a deadlock.

Fixed by avoiding to lock MDL_lock::m_rwlock with
MDL_map_partition::m_mutex locked. There is already infrastructure to
release the latter and acquire the former and guarantee that a reference
to an MDL_lock object is valid at the same time. It is implemented in
MDL_map_partition::move_from_hash_to_lock_mutex(), so the fix utilizes
it to remove the deadlock condition.

715. By Laurynas Biveinis

Null-merge lp:percona-server/5.5 rev 722

Branch metadata

Branch format:
Branch format 7
Repository format:
Bazaar repository format 2a (needs bzr 1.16 or later)
Stacked on:
This branch contains Public information 
Everyone can see this information.