I will be happy with any tracing capability. One of the early messages mentioned using a debugger in place of tracing, and that would be awful for diagnosing behavior.
On Fri, Jul 11, 2008 at 12:12 PM, Jay Pipes <[EMAIL PROTECTED]> wrote: > While this is true, Mark, the existing trace "packages" aren't > particularly effective either, IMHO, for the following reasons: > > * They are completely inconsistent (see opt_range.cc vs. storage/myisam > vs. Innodb) > * They are hacked into the server using a metric ton of #ifdef's which > cause build and test failures out the wazoo > * They are integrated into the code files, instead of being ancillary > (like dtrace is...) > > I believe the current plan is to get rid of the DBUG library > (include/my_dbug.h) and the 20K+ lines of DBUG_XXX code, and then to > backport custom tracing functionality (for a good example, see the > dbug_print, print_quick, etc, code in opt_range.cc) into a separate > library that can be called via a debugger or other client program. > > Would this work for you? > > -jay > > MARK CALLAGHAN wrote: >> gdb isn't a replacment for a trace package. If you remove DBUG and >> don't add back trace statements via another package, then it will be >> much more expensive to diagnose misbehavior. Debuggers are great when >> you know what you are looking for. They are inefficient when you don't >> know what to look for. If you only work on a small portion of the >> code, a debugger is OK. If you have to work on code throughout the >> server, then not having tracing is awful. And I think that anyone >> doing support (yes, a lot of the time, I am doing support) will agree >> with me. >> >> And if you make the trace package nice enough, you might be able to >> get storage engines to use it. >> > -- Mark Callaghan [EMAIL PROTECTED] _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
