Sven Sandberg wrote:
> Hi Mats,
>
> Mats Kindahl wrote:
[snip]
>>> +
>>> +# Warning: do not add more tests here. The binlog is in a bad state.
>>> +
>>
>> In that case, should you not reset the master (and the slave) to ensure
>> that the bad state is thrown away?
>
> Hmmm, I don't think so. That would remove the binlogs. If the test
> fails, it will be difficult analyze without the binlogs. Any test case
> executing next and using replication is supposed to source
> include/master-slave.inc anyway, which will reset master and slave.
OK. It was just a suggestion.
[snip]
>>> +--echo ---- autocommitted ----
>>>
>>> SET AUTOCOMMIT = 1;
>>>
>>> -INSERT INTO tndb VALUES (1);
>>> -INSERT INTO tmyisam VALUES (1);
>>> +INSERT INTO tmyisam VALUES (0);
>>> +INSERT INTO tinnodb VALUES (1);
>>> +INSERT INTO tndb VALUES (2);
>>
>> Any particular reason to change the values inserted into tndb and
>> tmyisam?
>
> Yes, I maintained the property that the N'th insert in the file inserts
> the value N. This makes it easier to see where the test fails, if it
> fails. It also makes it easier to see that the result file is as expected.
>
>> I think that you are again placing yourself for a difficult
>> merge, or causing a buggy merge.
>
> Since the test is essentially rewritten, I think it is *good* if we get
> a conflict in the (unlikely) case this file is concurrently edited by
> someone else. An auto-merge would be dangerous.
>
I'm not worried about conflicts, I'm worried about not getting conflicts
(as you demonstrated with the --weave bug, it can happen with bad
results). This looks dangerously close to reordering the lines, which
would trigger the bug if somebody changed the line.
If you feel this is safe, then go ahead. If nobody does an arbitrary
reordering of identical lines, we will probably have fewer problems with
--weave.
Just my few cents,
Mats Kindahl
--
Mats Kindahl
Lead Software Developer
Replication Team
MySQL AB, www.mysql.com
