Re: Syslog and pg_options (for RPMs)

On Thu, Feb 08, 2001 at 02:43:33PM -0500, Tom Lane wrote:
> Lamar Owen <lamar(dot)owen(at)wgcr(dot)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.

There is a program called "splogger" for that purpose.

Syslog's wire protocol stinks, but partly by design.

Good logging is hard because you don't want to stall real work
waiting to get the messages onto disk or out to the net, but you
also don't want to lose messages. The best you can do under those
circumstances is to buffer log-traffic spikes and hope the averaged
traffic is supportable. Compression can help a lot. Ultimately you
have to decide whether you'd rather stall or would rather lose
messages, if the traffic gets too heavy, and then live with the
result.

Nathan Myers
ncm(at)zembu(dot)com