Re: elog() proposal

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