Patch approved pending minor change. See inline.
Guilhem Bichot wrote:
> #At file:///home/mysql_src/bzrrepos_new/mysql-next-mr-opt-backporting-wl4800/ 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 included
> 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 (which
> 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."