Re: elog() proposal

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: elog() proposal
Date: 2002-02-21 15:15:11
Message-ID: 7545.1014304511@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2002-02-21 15:19:57 Re: Error with a SQL query 'between .. and .. and'
Previous Message darren 2002-02-21 14:51:06 Re: Replication