Tom Lane wrote:
> Lamar Owen <lamar.owen@wgcr.org> writes:
> > AOLserver is one example that successfully redirects dynamic linker
> > messages to it's own log.
> Oh? How? Are you sure they're not just piping stderr to a program
> of their own devising? That's basically what I'm recommending.
I'm not sure how they're going about it, but, I'll check.
> > A syslogger of stderr would make a nice place to pipe the output :-).
> > 'postmaster .... 2>&1 | output-to-syslog-program -f facility.desired' or
> > some such. But that obviates the need to support syslog _at_all_ in the
> > backend,
> 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).
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.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
