Thread: error handling in logging hooks

What is the intended way to handle errors in the new logging hook?  For
example, errors in establishing a connection to wherever a hook wants to
send things.

The reference implementation pg_logforward just uses fprintf(stderr) to
communicate its own errors, which doesn't seem ideal.

Calling elog(ERROR) in the logging hook causes death by recursion.  It
seems that some of the recursion protection infrastructure of elog.c
isn't exposed to the public, so it's not obvious how to use it.

Should logging hooks handle this themselves (could be complicated,
multiple hooks etc.), or should we try to build this into elog.c where
the hooks are called?

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".

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.

> 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.
        regards, tom lane

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.

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.

> >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.