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