Re: elog() proposal - Mailing list pgsql-hackers

Actually, it is even simpler.  Let's do this:

Client levels:
DEBUG, LOG, INFO, NOTICE, ERROR

Server levels:
    DEBUG, INFO, LOG, NOTICE, ERROR, FATAL, CRASH

Where client LOG shows LOG, INFO and higher, and server INFO shows INFO,
LOG and higher.

Not sure if INFOLOG was clearer or not.

---------------------------------------------------------------------------

Bruce Momjian wrote:
> 
> OK, let me throw out a modified proposal that attempts to deal with
> these issues, and avoids creating a complicated error reporting system
> that few will understand or be able to control.
> 
> How about if we have a new *_min_message setting, INFOLOG, which grabs
> client and server log info.  This will allow a unified system where the
> client_min_message can be set to:
> 
>     DEBUG, INFOLOG, INFO, NOTICE, ERROR
> 
> default, INFO, and the server_min_message can be:
> 
>     DEBUG, INFOLOG, LOG, NOTICE, ERROR, FATAL, CRASH
> 
> default, LOG.
> 
> Basically we do this:
> 
>     elog(INFO, ...)
> 
> and this prints to the client if its value is INFO or less, and
> prints to the server if its level is INFOLOG or less.  In this case:
> 
>     elog(LOG, ...)
> 
> it prints to the client if its value is INFOLOG or less, and prints to
> the server if its level is LOG or less.
> 
> This allows elog() to go to both places, if desired, and allows control
> in a fine-grained manner.
> 
> This handles Tom's issue that DEBUG should be visible to the client if
> it wishes.
> 
> Peter's issue of sending separate messages to client and server can be
> handled with two elog messages, one LOG, another INFO.
> 
> This is all backward compatible because it does not remove any codes,
> only adds elog levels INFO and LOG, which are lower than NOTICE.
> 
> Also, I like Tom's idea of DEBUG4 in the code, rather than testing the
> debug level.  Instead, do the level testing in elog() function, which
> makes sense.  This does allow DEBUGx as a possible debug level.
> 
> ---------------------------------------------------------------------------
> 
> Tom Lane wrote:
> > Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > > First, I think ERROR/DEBUG/NOTICE/FATAL, etc are too generic and cause
> > > compile problems/warnings, especially with Perl.  I suggest renaming all
> > > elog levels to PG*, so it would be PGERROR and PGINFO.  We could also do
> > > E_* or E*.  I am interested in other opinions.
> > 
> > We must put a prefix on these things.  I have no strong opinion about
> > which prefix to use, but the change is long overdue.
> > 
> > > Second, I propose adding two GUC variables that control how much elog()
> > > info is sent to the server and client logs.  I suggest
> > > 'server_message_min' with possible values DEBUG, LOG, NOTICE, ERROR,
> > > FATAL, CRASH; and 'client_message_min' with possible values INFO,
> > > NOTICE, ERROR, FATAL, CRASH.
> > 
> > client_message_min cannot usefully be set higher than ERROR.  It will
> > certainly break libpq, for example, if 'E' messages don't come back when
> > a command fails.  I also object to the idea that client_message_min
> > should not be settable to a level that allows DEBUG messages to be seen.
> > That would frequently save having to scrounge in the postmaster log,
> > which is not that easy if you're a client on a different machine.
> > 
> > > We currently have 'debug_level' which controls how much debug
> > > information is sent to the server logs.  I believe this would have to
> > > remain because it controls how _much_ DEBUG output is printed.  We could
> > > go with some kind of hybrid where "DEBUG 5" sets DEBUG as the minimum
> > > reporting mode with level 5.
> > 
> > I think you missed the point of my previous suggestion: let's invent
> > multiple DEBUG tags, for example DEBUG, DEBUG2, DEBUG3, DEBUG4,
> > and replace code like
> > 
> >     if (DebugLevel > 4)
> >         elog(DEBUG, ...);
> > 
> > with
> > 
> >     elog(PGDEBUG4, ...);
> > 
> > This way, the log verbosity is controllable by a single mechanism rather
> > than two independent variables.  You can set server_message_min to, say,
> > DEBUG or DEBUG4.
> > 
> > Finally, I still object strongly to the notion that any of these message
> > levels should be hard wired as "never send to client" or "never send to
> > log"; if you can't imagine scenarios where people will want to override
> > that behavior, then your imagination is lacking.  I want that choice to
> > be completely configurable.  What I'd suggest is an exclusion mask.
> > Suppose we order the levels as
> > 
> > PGDEBUG4, PGDEBUG3, PGDEBUG2, PGDEBUG, PGLOG, PGINFO, PGNOTICE, PGERROR,
> > PGFATAL, PGCRASH.
> > 
> > Then I think from the client's point of view the only knob needed is
> > client_message_min (settable between PGDEBUG4 and PGERROR, with default
> > PGINFO).  On the server side we could have server_message_min (settable
> > between PGDEBUG4 and PGCRASH, with default probably PGLOG) plus a
> > list server_message_exclude of levels not to log, which could have
> > default value "PGINFO,PGNOTICE" (internally this would become a bitmask
> > so it would be cheap to test).
> > 
> > It'd be possible to unify server_message_min and server_message_exclude
> > into a single parameter that's just a message level bitmask, but I think
> > the two separate parameters would be easier to deal with; otherwise you
> > end up with an awfully verbose parameter value.
> > 
> >             regards, tom lane
> > 
> 
> -- 
>   Bruce Momjian                        |  http://candle.pha.pa.us
>   pgman@candle.pha.pa.us               |  (610) 853-3000
>   +  If your life is a hard drive,     |  830 Blythe Avenue
>   +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
> 
> http://archives.postgresql.org
> 

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026