Sergei, hi.
> Hi!
>
> On Oct 24, Andrei Elkin wrote:
>> ChangeSet@stripped, 2007-10-24 09:31:23+03:00, aelkin@stripped +10 -0
>> Bug #27571 asynchronousity in setting mysql_`query`::error and
>> Query_log_event::error_code
>>
>> A query can perform completely having the local var error of
>> mysql_$query zero, where $query in insert, update, delete, load,
>> and be binlogged with error_code e.g KILLED_QUERY while there is
>> no reason do to so. That can happen because Query_log_event
>> consults
>> thd->killed flag to evaluate error_code.
>>
>> Fixed with implementing a scheme suggested and partly implemented
>> at time of bug@22725 work-on. error_status is cached immediatly
>> after the control leaves the main rows-loop and that instance
>> always corresponds to `error' the local of mysql_$query
>> functions. The cached value is passed to Query_log_event
>> constructor, not the default thd->killed which can be changed in
>> between of the caching and the constructing.
>
> Make your comment lines shorter than 80 characters.
>
done ;)
>> A simulation test is provided although it can not be easily made deterministic.
> So it has
>> to be moved to the manual suite.
>>
>> The current changeset is limited to capture only UPDATE
>> query. The rest of modifying DMS:s will be handled by deploying
>> the current pattern upon successful review of it.
>
> This comment ^^^ is no longer true.
>
thanks. To be removed.
>> diff -Nrup a/mysql-test/t/binlog_killed.test b/mysql-test/t/binlog_killed.test
>> --- a/mysql-test/t/binlog_killed.test 2007-06-07 21:25:21 +03:00
>> +++ b/mysql-test/t/binlog_killed.test 2007-10-24 09:31:16 +03:00
>> @@ -99,6 +99,7 @@ let $ID= `select connection_id()`;
>> send insert into t1 values (bug27563(),1);
>>
>> connection con1;
>> +--replace_result $ID ID
>> eval kill query $ID;
>
> I thought we agreed to remove these replace_result's.
> They serve no purpose here, either remove them or remove
> disable_result_log (and disable_query_log)
>
And I restored that in a part that is executable.
The hunk you are referring to is within if(0)-block which was left
such "commented-out" awaiting for the future fixes.
I removed the block after looking at the bugs' state to find them
closed.
In my current tests
1. we are better to have at least select's results e.g to prove
"killing inside of select loops is safe as before".
that's why i don't like
disable query_log and results.
2. we don't have to play with disable/enable_abort_on_error as
there is --error in order not to be aborted.
All in all, it'd be just a bit of inconsistentcy with the previous bug
test's layout. Still preserving more info from query log is only for
good if it will come to analyze a failure.
Agreed?
regards,
andrei
