Lamar Owen <lamar.owen@wgcr.org> writes:
> There are still scads of fprintf(stderr, "some error message from
> postmaster or backend") lying around, in CURRENT as of this morning at
> 1:00AM EDT. Some are things such as the usage message -- others are
> obviously (IMHO) things that need to be sent to the logs. We're not
> replacing the system fprintf , are we? (my assumption is that we are
> NOT). The usage of puts(), OTOH, has been well nigh eradicated.
> Where is elog() safe? (Going to Bruce 'comb through the archives' mode
> here...)
Most places. Not in client communication failures, obviously,
else you'd have instant death by recursion since elog tries to
report to the client (if any) as well as the system log.
That case might (perhaps should be) dealt with by means of some
internal state flags inside elog.
However, it's folly to imagine that we will ever get rid of stderr
output entirely. One glaring example is that on most platforms,
if you have a failure while trying to load a dynamic-link library,
the dynamic linker will emit useful messages (like the names of
unresolved symbols) on stderr. It will never be acceptable to throw
that info away, nor do we have a way to capture it and send it
elsewhere than stderr.
Given these considerations, I'm not all that excited about mounting a
holy war on stdout/stderr messages in the backend code. It'd be more
profitable to leave the code as-is and figure out a way to cause
stdout/stderr output to be logged in a more admin-friendly manner.
I like the idea of piping the output to a log-rotation program.
regards, tom lane
