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*, ...).
Thread
Proposal: extension to Log interface to get error message writtenindependently of falcon-debug-maskOlav Sandstaa17 Oct
  • Re: Proposal: extension to Log interface to get error message writtenindependently of falcon-debug-maskJim Starkey17 Oct
    • Re: Proposal: extension to Log interface to get error message writtenindependently of falcon-debug-maskAnn W. Harrison17 Oct
    • Re: Proposal: extension to Log interface to get error message writtenindependently of falcon-debug-maskOlav Sandstaa10 Mar
      • Please review implementation of WL#4380 (Hooks for crashing Falcon andits recovery)Vladislav Vaintroub10 Mar
      • Re: Proposal: extension to Log interface to get error message writtenindependently of falcon-debug-maskVladislav Vaintroub10 Mar
        • Re: Proposal: extension to Log interface to get error message writtenindependently of falcon-debug-maskOlav Sandstaa15 Mar
          • Re: Proposal: extension to Log interface to get error message writtenindependently of falcon-debug-maskOlav Sandstaa23 Jun
            • Re: Proposal: extension to Log interface to get error message writtenindependently of falcon-debug-maskKevin Lewis23 Jun
            • Re: Proposal: extension to Log interface to get error message writtenindependently of falcon-debug-maskVladislav Vaintroub23 Jun
      • Re: Proposal: extension to Log interface to get error message writtenindependently of falcon-debug-maskJim Starkey10 Mar