Jorgen Loland a écrit, Le 22.11.2010 11:03:
>>> === modified file 'sql/opt_range.cc'
>>> --- a/sql/opt_range.cc 2010-10-22 13:36:50 +0000
>>> +++ b/sql/opt_range.cc 2010-11-17 12:27:39 +0000
>>> === modified file 'sql/sql_select.cc'
>>> --- a/sql/sql_select.cc 2010-11-11 13:25:53 +0000
>>> +++ b/sql/sql_select.cc 2010-11-17 12:27:39 +0000
>> GB if you apply a temporary workaround for the "uninitialized memory in
>> print_keyuse" problem/crash, do you get any crash with
>> ./mtr --opt-trace-protocol
>> in your tree?
> Lots and lots of JSON syntax error asserts for subqueries.
>> GB There remains one NO_OPT_TRACE_IN_RANGE_OPT in opt_range.cc, have you
>> decided how to eliminate it?
> I never saw the problem that required us to compile this in. This code
> has never been active in my trees, so to me it can be removed. Since you
> don't want it either, it's gone...
Mmmm it's not that I don't want it; in the past it caused me problems
(syntax errors when using stored functions), so I disabled it (having
the good excuse that it was a function call inside range opt and range
opt tracing would be re-done properly).
Suppressing the #ifdef has effects, it explains the big diff of
optimizer_trace_no_prot.result in your last commit: some statements
which were not traced are now traced (starting around line 5547 in the
You can push though, I will think about this more and decide whether I
want to re-disable tracing in this place.