Re: elog() proposal

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(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026