MySQL Lists are EOL. Please join:

List:Commits« Previous MessageNext Message »
From:Sergei Golubchik Date:September 30 2010 4:33pm
Subject:Re: bzr commit into mysql-5.5-bugfixing branch (davi:3208)
Bug#49938
View as plain text  
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 :(

Regards,
Sergei
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