Re: bk commit into 5.2 tree (davi:1.2605) BUG#25858

[Davi Arnaut]

Konstantin Osipov wrote:
> * Davi Arnaut <davi@stripped> [07/09/06 08:14]:
>> ChangeSet@stripped, 2007-09-06 00:54:06-03:00, davi@stripped +21 -0
>>   Bug#25858 Some DROP TABLE under LOCK TABLES can cause deadlocks
>>   
>>   When a client (connection) holds a lock on a table and attempts to
>>   drop (obtain a exclusive lock) on a second table that is already held
>>   by a second client and the second client then attempts to drop the table
>>   that is held by the first client, leads to a circular wait deadlock. This
>>   scenario is very similar to trying to drop (or rename) a table while
>>   holding read locks and are correctly forbidden.
>>   
>>   The solution is to allow a drop table operation to continue only if the
>>   table being dropped is write (exclusively) locked, or if the table is
>>   temporary, or if the client is not holding any locks. Using this scheme
>>   prevents the creation of a circular chain in which each client is waiting
>>   for one table that the next client in the chain is holding.
>>   
>>   This is incompatible change, as can be seen by number of tests cases
>>   that needed to be fixed, but is consistent with respect to behavior of
>>   the different scenarios in which the circular wait might happen.
> 
> This patch is good and does the job.
> 
> However, the deadlock is potentially present wherever we call
> lock_table_name() under LOCK TABLES for any table that is not in the locked
> list.
> 
> Could you perhaps move the part that checks that the table is in
> the list of LOCK TABLES to lock_table_name?
> 
> Here's how it could look like:
> 

[..]

> 
> 
> I'm eager to hear what that would break and why it won't work.
> 

No new broken tests.

-- 
Davi Arnaut, Software Engineer
MySQL Inc, www.mysql.com

Are you MySQL certified?  www.mysql.com/certification