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
List-Archive: http://lists.mysql.com/falcon/40
Message-Id: <48F88D22.90201@nimbusdb.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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*, ...).