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.