Horton

Re: Proposal: More structured logging

Peter Eisentraut <peter.eisentraut@enterprisedb.com>

View thread
From: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
To: Ronan Dunklau <ronan.dunklau@aiven.io>, pgsql-hackers@lists.postgresql.org
Date: 2021-09-01T07:36:50Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Fix ruleutils.c's dumping of whole-row Vars in more contexts.

On 13.08.21 15:23, Ronan Dunklau wrote:
> The logging system already captures a lot of information in the ErrorData. But
> at present there is no way for a log message authors to include more metadata
> about the log outside of the log message itself. For example, including the
> extension name which can be useful for filtering / dispatching log messages.
> This can be done in the log message itself, but that requires specialized
> parsing in the log output.
> 
> Even though among the available loggers in core, only the csv logger would be
> able to make sense of it, I feel it would be beneficial to add a tagging system
> to logs, by adding different (tag, value) combinations to a log entry, with an
> API similar to what we do for other ErrorData fields:
> 
> ereport(NOTICE,
>   (errmsg("My log message")),
>   (errtag("EMITTER", "MYEXTENSION")),
>   (errtag("MSG-ID", "%d", error_message_id))
> );

What are some more examples of where this could be used?  The extension 
name could be added more or less automatically to ereport() calls.  I 
don't know what the MSG-ID is supposed to be.  Are there other use cases?