List:Commits« Previous MessageNext Message »
From:Guilhem Bichot Date:November 22 2010 12:50pm
Subject:Re: bzr commit into mysql-next-mr-bugfixing branch (jorgen.loland:3233)
WL#5594
View as plain text  
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.

Thread
bzr commit into mysql-next-mr-bugfixing branch (jorgen.loland:3233)WL#5594Guilhem Bichot20 Nov
  • Re: bzr commit into mysql-next-mr-bugfixing branch (jorgen.loland:3233)WL#5594Jorgen Loland22 Nov
    • Re: bzr commit into mysql-next-mr-bugfixing branch (jorgen.loland:3233)WL#5594Guilhem Bichot22 Nov