Bug #43867 ALTER TABLE on a partitioned table causes unnecessary
deadlocks Backport of revno: 2617.68.35 The problem was that if one connection is running a multi-statement transaction which involves a single partitioned table, and another connection attempts to alter the table to drop a non-existing partition, (which of course will fail), the first connection still gets ER_LOCK_DEADLOCK and cannot proceed anymore. This bug is no longer reproducable. This has also been tested with the patch for Bug#46654 "False deadlock on concurrent DML/DDL with partitions, inconsistent behavior" which concerned a similar problem but where the ALTER TABLE is semantically correct. Test case added in partition_sync.test.
Showing
Please register or sign in to comment