Re: error handling in logging hooks

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: error handling in logging hooks
Date: 2012-08-11 18:05:30
Message-ID: 9482.1344708330@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter_e(at)gmx(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-08-11 21:23:04 View options (as in "security_barrier") break pg_dump
Previous Message Michael Meskes 2012-08-11 09:59:02 Re: Issue in Behavior of Interval Datatype