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.