MySQL Lists are EOL. Please join:

List:Commits« Previous MessageNext Message »
From:Davi Arnaut Date:September 30 2010 4:57pm
Subject:Re: bzr commit into mysql-5.5-bugfixing branch (davi:3208) Bug#49938
View as plain text  
On 9/30/10 1:33 PM, Sergei Golubchik wrote:
> Hi, Davi!
>
> On Sep 29, Davi Arnaut wrote:
>> Hi Sergei,
>>
>> On 9/29/10 2:51 AM, Sergei Golubchik wrote:
>>> Hi, Davi!
>>>
>>> On Sep 29, Davi Arnaut wrote:
>>>> # At a local mysql-5.5-bugfixing repository of davi
>>>>
>>>>    3208 Davi Arnaut	2010-09-29
>>>>      Bug#49938: Failing assertion: inode or deadlock in fsp/fsp0fsp.c
>>>>
>>>>      The problem was that, for storage engines that do not support
>>>>      truncate table via drop and recreate, the delete_all_rows
>>>>      method could be invoked with a shared metadata lock, causing
>>>>      problems if the engine needed exclusive access to some internal
>>>>      metadata. This problem originated with the fact that there is
>>>>      no truncate specific handler method, which ended up leading
>>>>      to a abuse of the delete_all_rows method that is primarily
>>>>      used for delete operations without a condition.
>>>
>>> delete_all_rows() should always be fine with a shared metadata lock.
>>> Why would innodb expect an exclusive lock here?
>>
>> InnoDB does a internal drop and recreate. The intention of this new
>> truncate method is exactly this, allow certain engines to internally
>> drop and recreate its tables, without complicating delete_all_rows
>> which at this point becomes confined to delete statements.
>
> Uhm. I see.
>
> I'd personally would just say that MySQL calls delete_all_rows to empty
> the table and that delete_all_rows alone is sufficient - it provides all
> necessary information to the engine about the server intentions (to make
> the table empty somehow). The fact that InnoDB implements emptying via
> drop+recreate and thus needs an exclusive lock is the detail of the
> internal implementation of this engine and InnoDB can upgrade its
> internal metadata lock internally, if needed.
>
> But perhaps you cannot say that anymore :(

I think that letting the engine upgrade the lock has the potential for 
deadlock scenarios (just guessing..). Anyway, not that it matters much.. 
we could have fixed it in the context of delete_all_rows but I think we 
would just end up complicating things even further.

After the patch, delete_all_rows should behave somewhat as you describe, 
it will empty the table but should also perform (as necessary) integrity 
checks and, also, the binary log will be active, etc -- the regular 
stuff for delete. With truncate we can limit the scope to no integrity 
checks at all, no regular binary log implications and reduce it, at 
least in concept, to a somewhat normal DDL.

I would say it is a bug fix mixed with a bit of re-factoring :)

Regards,

Davi
Thread
bzr commit into mysql-5.5-bugfixing branch (davi:3208) Bug#49938Davi Arnaut29 Sep
Re: bzr commit into mysql-5.5-bugfixing branch (davi:3208)Bug#49938Sergei Golubchik29 Sep
  • Re: bzr commit into mysql-5.5-bugfixing branch (davi:3208) Bug#49938Davi Arnaut29 Sep
    • Re: bzr commit into mysql-5.5-bugfixing branch (davi:3208)Bug#49938Sergei Golubchik30 Sep
      • Re: bzr commit into mysql-5.5-bugfixing branch (davi:3208) Bug#49938Davi Arnaut30 Sep