Re: error handling in logging hooks

On Sat, 2012-08-11 at 14:05 -0400, Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
> > What is the intended way to handle errors in the new logging hook?
> 
> I'm not sure there is anything very useful you can do to "handle" them,
> if by "handle" you mean "report somewhere".

Yes, they ought to be written to the normal log.  I just don't want them
to be sent back to the logging hook.  I guess it could depend on whether
the hook does something with output_to_server, but I think the regular
log would be a good fallback in any case.

> >From the point of view of elog.c, anything that might go wrong inside
> a logging hook is not very different from an error in write(), which
> it ignores on the basis that it can't report it to anybody.
> 
> Another comparison point is syslog(3), which doesn't even have a
> defined API for reporting that it failed, even though there are
> certainly cases in which it must.  I think the design intention is
> that syslog messages are "fire and forget"; if they don't get to
> their destination, it's not the originating app's problem.  I do not
> think we can do better than that for arbitrary logging hooks.

Well, there are plenty of ereport calls in syslogger.c, for example, so
I don't think that analogy really holds.  Also, syslog itself will
report something to its own log when there is a misconfiguration or
communication problem for remote syslogging.

> > The reference implementation pg_logforward just uses fprintf(stderr) to
> > communicate its own errors, which doesn't seem ideal.
> 
> That seems pretty broken, even without considering what's likely to
> happen on Windows.  It should just shut up, if you ask me.

That's not really an acceptable solution.  If I'm trying to log to a
network resource and the setup fails, I should have *some* way to learn
about that.