From: Date: January 9 2009 10:05am
Subject: Re: bzr commit into mysql-5.1-bugteam branch (davi:2741) Bug#37016
List-Archive: http://lists.mysql.com/commits/62771
Message-Id: <49671366.9090305@sun.com>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT

Hello,

Davi Arnaut a écrit, Le 01/08/2009 11:13 PM:
> 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.

Mmmm as it is 5.1-GA I would not add anything which is not strictly 
needed (there is an old MySQL policy somewhere about this). Here we are 
adding a few lines of code to a case which was not the subject of the 
bug report, and for which there is no known bug. So I wouldn't add those 
lines to 5.1.
But for 6.0, if you think those lines bring any good, go ahead, I can't 
see the harm which they would do.

Ok to push.