Re: Syslog and pg_options (for RPMs) - Mailing list pgsql-hackers

From Tatsuo Ishii
Subject Re: Syslog and pg_options (for RPMs)
Date
Msg-id 20010209111257Z.t-ishii@sra.co.jp
Whole thread Raw
In response to Re: Syslog and pg_options (for RPMs)  (Lamar Owen <lamar.owen@wgcr.org>)
Responses Re: Syslog and pg_options (for RPMs)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> > Precisely my point.  I think working hard on syslog support inside elog
> > is misplaced effort.
> 
> Well, I can think of a few things:
> 1.)    Some messages are more important than others.  Syslog levels are
> useful to segreggate debug, errors, informational, and critical
> messages.
> 2.)    Critical messages might need to go to more than one place, while
> debug messages might need to be dropped silently unless further
> configuration, etc, is performed.
> 3.)    Some messages need immediate attention -- syslog can go to the
> console for level 'crit' messages.
> 
> I know that those three points are part of the same point -- but stderr
> is but a single stream, relegating all messages to the same priority.  I
> might want to keep critical messages far longer than debug messages.  I
> might want to keep FATAL, REALLYFATAL, and even ERROR messages longer
> than logs of queries (a likely scenario).

Good point.

> Syslog support in elog(), with proper errorlevel coding, allows the
> admin to segregate messages as he sees fit.  Using logger(1) means all
> messages are the same.

Totally agreed.

There are still many loggings using just plain fprintf(). They should
be replaced by elog(DEBUG) or elog(NOTICE), IMHO.
--
Tatsuo Ishii


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Plan for straightening out the include-file mess
Next
From: Tom Lane
Date:
Subject: Re: Syslog and pg_options (for RPMs)