Re: Patch review for logging hooks (CF 2012-01) - Mailing list pgsql-hackers

From Martin Pihlak
Subject Re: Patch review for logging hooks (CF 2012-01)
Date
Msg-id 4F16EF81.9070106@gmail.com
Whole thread Raw
In response to Re: Patch review for logging hooks (CF 2012-01)  (Fujii Masao <masao.fujii@gmail.com>)
Responses Re: Patch review for logging hooks (CF 2012-01)
List pgsql-hackers
On 01/18/2012 03:56 AM, Fujii Masao wrote:
> or syslog process (if you use syslog). So ISTM that there is no
> guarantee that the order of log messages processed by the
> hook is same as that of messages written to the log file. For
> example, imagine the case where two backends call EmitErrorReport()
> at the same time. Is this OK? If not, the hook might need to be
> in syslogger.

For high volume logging I'd avoid going through the syslogger. One
big issue with syslogger is that it creates a choke point - everything
has to pass through it, and if it cannot keep up it starts stalling
the backends. Also, in EmitErrorReport the hook gets to have access
to the actual ErrorData structure -- that makes filtering and looking
at message content much simpler.

> EmitErrorReport() can be called before shared library like Martin's
> pg_logforward is preloaded. Which means that the hook may miss
> some log messages. Is this OK?
> 

True, even though the shared or local preload libraries are loaded
quite early in PostmasterMain/PostgresMain there is a chance that
some messages (mostly initialization failures) are missed. I guess
there is no way to avoid this with module based approach. But IMHO
this is acceptable -- when the backend fails to initialise, it cannot
be  assumed that the logging subsystem is set up properly. I guess it
deserves at least a comment though. Thanks for pointing this out.

regards,
Martin


pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: patch: fix SSI finished list corruption
Next
From: Andrew Dunstan
Date:
Subject: Re: Patch review for logging hooks (CF 2012-01)