Mats Kindahl wrote:
>> Mats Kindahl wrote:
>> [...]
>>> diff -Nrup a/sql/slave.cc b/sql/slave.cc
>>> --- a/sql/slave.cc 2007-10-13 14:58:06 +02:00
>>> +++ b/sql/slave.cc 2007-10-20 20:16:08 +02:00
>> [...]
>>> @@ -1905,7 +1915,8 @@ static int exec_relay_log_event(THD* thd
>>> }
>>> if (slave_trans_retries)
>>> {
>>> - if (exec_res && has_temporary_error(thd))
>>> + int temp_err;
>>> + if (exec_res && (temp_err= has_temporary_error(thd)))
>>> {
>>> const char *errmsg;
>>> /*
>>> @@ -1953,15 +1964,19 @@ static int exec_relay_log_event(THD* thd
>>> "the slave_transaction_retries variable.",
>>> slave_trans_retries);
>>> }
>>> - else if (!((thd->options & OPTION_BEGIN) &&
>>> opt_using_transactions))
>>> + else if (exec_res && !temp_err ||
>>> + (opt_using_transactions &&
>>> + rli->group_relay_log_pos ==
> rli->event_relay_log_pos))
>>
>> This looks fishy: the condition of the `else if ()' does not depend on
>> the truth value of `(opt_using_transactions &&
>> rli->group_relay_log_pos == rli->event_relay_log_pos)'. In fact,
>> `(opt_using_transactions ...)' will never be evaluated due to shortcut
>> evaluation. Consider the following case analysis:
>>
>> 1. If exec_res==0 before the `if()', then the
>> condition of the `else if()' is never true.
>
> False. The evaluation of the else if() will be true if exec_res == 0,
> opt_using_transactions != 0 , and rli->group_relay_log_pos ==
> rli->event_relay_log_pos. Hence the else if() can be true even when
> exec_res == 0.
You are right, I read the code with the precedence of && and ||
switched. Sorry.
For clarity, I would suggest to put parentheses around && within ||.
>> ## BEGIN OUTPUT #################################################
[...]
>> ## END OUTPUT ###################################################
>
> Yes, this is because the test case triggered BUG#31702, which I have
> fixed and got a review of. You need to apply the patch for this before
> you can execute the test case for this bug.
OK, will try this. Then I will need some more time to understand the bug
properly before ok'ing it...
--
Sven Sandberg, Software Engineer
MySQL AB, www.mysql.com
