Tor Didriksen a écrit, Le 23.05.2011 09:12:
> #At file:///export/home/didrik/repo/next-mr-opt-backporting-wl4800/ based on
> revid:guilhem.bichot@stripped
>
> 3313 Tor Didriksen 2011-05-23
> comments on TODO list
>
> modified:
> WL4800_TODO.txt
> sql/opt_trace.h
> === modified file 'WL4800_TODO.txt'
> --- a/WL4800_TODO.txt 2011-05-20 13:15:22 +0000
> +++ b/WL4800_TODO.txt 2011-05-23 07:12:10 +0000
> @@ -27,6 +27,7 @@ version number in order to distinguish b
> not forget to bump the version when doing certain changes (and: what
> changes? any little change? maybe).
> Guilhem suggests: don't have a version.
> +I agree.
ok
> C3) Jorgen wrote: The optimizer may have second thoughts about which access method
> to
> use for a table. This should be traced. See example query (1) where
> @@ -43,12 +44,14 @@ Guilhem asks: good idea, but how much is
> --explain-protocol, --sp-protocol, --view-protocol make all tests
> fail. Maybe I can merely move this as an idea in a comment in mysqltest.cc
> near the definition of opt-trace-protocol?
> +This would be a relly nice feature. Don't know how much work it is though.
We would also need to define it.
Right now, the trace is put in the test's output, so one gets:
normal test output ("echo"-based informative comments, query, result)
trace
normal test output
trace
so the reader sees the "context" of the trace.
If we dump to a separate file:
- how do we name it: <testname>.opt_trace?
- what do we put in the file? it will look like
trace
trace
which will be harder to relate to a certain test portion. The
OPTIMIZER_TRACE table does contain the query, but for tests which run
the same query several times, the query is not enough context.
We can improve a bit:
lineno trace
lineno trace
where lineno is the number of the line in the test file which caused
this trace.
It's still not as good as the "directly-in-output" trace which we have now.
I suggest we continue living with the current situation. Making tests
fail causes server restarts and thus slowdowns, on the other hand, we
don't use the option that much, so the slowdown is rarely experienced...
I think we use --opt-trace-protocol to run the full suite and grep all
traces for a certain word, to find tests which exercise a certain piece
of the optimizer. That is not so common. I alternatively use
--mysqld=--optimizer-trace=enabled=on; it does not print the trace; but
is good enough to find trace-related crashes or bad query results.
> C5) should the debug binary really assert(0) if json syntax error? is it a
> good idea at the customer's? On the other hand, how to make sure a
> developer notices a syntax error when running tests?
> sql_print_warning() is an idea.
> Guilhem suggests: keep it as it is (assert(0))
> +Let's keep it, at least for now.
ok
