Jorgen Loland a écrit, Le 14.12.2010 13:10:
> Hi Guilhem,
> Patch approved pending minor change. See inline.
> Guilhem Bichot wrote:
>> based on revid:guilhem@stripped
>> 3236 Guilhem Bichot 2010-11-26
>> Fix for a bug: if a sub-statement shouldn't be traced but is
>> inside a traced
>> top-statement, the sub-statement's trace structures would be
>> inside the top-statement's trace instead of being invisible.
>> @ mysql-test/r/optimizer_trace2.result
>> Without the code fix, the trace of CALL would contain the trace
>> of "select TRACE+NULL..." even though the latter one uses
>> OPTIMIZER_TRACE (which shouldn't be traced).
>> @ sql/opt_trace2server.cc
>> Fix for the bug. The "allocated_here" part is for another bug
>> could happen if running out of memory): we should free opt_trace
>> only if we allocated it in this frame.
>> === added file 'mysql-test/t/optimizer_trace2.test'
>> --- a/mysql-test/t/optimizer_trace2.test 1970-01-01 00:00:00 +0000
>> +++ b/mysql-test/t/optimizer_trace2.test 2010-11-26 09:28:38 +0000
>> @@ -0,0 +1,25 @@
>> +# Continuation of tests for optimizer trace
>> +--source include/have_optimizer_trace.inc
>> +# check that if a sub-statement should not be traced,
>> +# it is not traced even if inside a traced top statement
>> +set optimizer_trace="enabled=on,end_marker=on";
>> +set optimizer_trace_offset=0, optimizer_trace_limit=100;
>> +delimiter |;
>> +create procedure p1(arg char(1))
>> + declare res int;
>> + declare dummy varchar(1);
>> + select 1 into res from dual;
>> + select TRACE+NULL into dummy from
>> information_schema.OPTIMIZER_TRACE limit 1;
>> + select 2 into res from dual;
>> +call p1("c")|
>> +# we should not see the trace of "select TRACE+NULL..."
> Please expand this comment along the lines of
> "... because tracing is disabled when OPTIMIZER_TRACE table is read."
fixed (soon pushed).