Hello,
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
result file).
You can push though, I will think about this more and decide whether I
want to re-disable tracing in this place.

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.