From: Date: January 8 2009 11:13pm
Subject: Re: bzr commit into mysql-5.1-bugteam branch (davi:2741) Bug#37016
List-Archive: http://lists.mysql.com/commits/62754
Message-Id: <49667A6D.8060706@Sun.COM>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT

On 1/8/09 7:30 PM, Davi Arnaut wrote:
> On 1/8/09 7:20 PM, Guilhem Bichot wrote:
>> Hello,
>>
>> Davi Arnaut a écrit, Le 12/13/2008 11:58 AM:
>>> # At a local mysql-5.1-bugteam repository of davi
>>>
>>> 2741 Davi Arnaut 2008-12-13
>>> Bug#37016: TRUNCATE TABLE removes some rows but not all
>
> [..]
>
>>> + ha_autocommit_or_rollback(thd, 0);
>>> + end_active_trans(thd);
>>> +
>>> DBUG_RETURN(error);
>>> }
>>
>> The last 3 added lines above, are for a situation which is not
>> row-by-row deletion, so what is the reason they are added (how do they
>> relate to the bug report)?
>> I believe you describe this change with "If the truncation is emulated
>> by a table recreation, always issue a implicit commit", but, was there a
>> problem at all when using table recreation? Why was the addition needed?
>>
>
> Table recreation can't be rolled back as some others DDL, so it's usual
> to issue a implicit commit before and after the statement is executed so
> that the TRUNCATE TABLE transaction is properly finished even in the
> recreation case.
>
> This hasn't much impact on 5.1, but its important for the future as this
> will guarantee that metadata locks are released. On 6.0, almost all
> DDL's are automtically committed at the end. So, this is more of a
> cleanup for now. Any objections?
>

Just remembered another reason: to keep things consistent between 
between truncate by recreation and row-by-row deletion.. both will 
commit. You are right that this addition is not needed, but IMHO it's 
worth it.

Regards,

-- Davi Arnaut