|List:||Falcon Storage Engine||« Previous MessageNext Message »|
|From:||Jim Starkey||Date:||October 17 2008 1:03pm|
|Subject:||Re: Proposal: extension to Log interface to get error message written|
independently of falcon-debug-mask
|View as plain text|
Olav Sandstaa wrote: > > Based on the discussion we have had by email about writing to MySQL's > error log file and my need for always getting the error message about > problems to the serial log written independently of what the status of > the --falcon-debug-mask is, I propose following extention to the Log:: > interface: > > Alterantive 1 (based on Ann's suggestions in an earlier email): > =========== > > * Introduce a new log category called "Fatal" (or something similar) > that always get written to the error log independently of what the > user has specified in the --falcon-debug-mask. > * Example: > > Log::log(Fatal, "This text will always go to the error log > file\n"); > > Note: This log category will possibly be documented in the MySQL > documentation along with the others, but the user not be allowed to > turn it off if she sets a debug-mask that does not enable it. > > Alternative 2: > ========== > > * Extend the Log:: interface with a new method called fatal() (or > error()) that will always write the message to the error log file > * Example: > > Log::fatal("This text will always go to the error log file, and > by the way Falcon has just crashed\n"); > > or > > Log::error("This text will always go to the error log file, and > by the way Falcon has just crashed\n"); > > * "Advantage" of this is that it does not interfere with the > falcon-debug-mask and the user visibility of this. > > Any strong preference for any of these? Any feedback or other > suggestions? > > PS: This is not about printf and clashes with the server's log > writing, it is just to define an interface that can be used for > messages that we want to get out with having the user needing to > specify an appropriate debug flag . > > Regards, > Olav > > PS A bonus proposal: I consider removing the implementation of > Log::print() as it uses printf directly if there is no particular use > for it (I do not think it is used anywhere) > > > > The two alternative are not mutually exclusive. The primary mechanism is a new message class "Fatal". There is also a secondary convenience method Log::fatal(const char*, ...) that logs the message with that bit in a manner analogous to Log::debug(const char*, ...).