Re: Add jsonlog log_destination for JSON server logs - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Add jsonlog log_destination for JSON server logs
Date
Msg-id YgW66yQdmXX17VQs@paquier.xyz
Whole thread Raw
In response to Re: Add jsonlog log_destination for JSON server logs  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
List pgsql-hackers
On Thu, Feb 10, 2022 at 07:45:17PM -0300, Alvaro Herrera wrote:
> From what I hear in the container world, what they would *prefer* (but
> they don't often get) is to receive the JSON-format logs directly in
> stderr from the daemons they run; they capture stderr and they have the
> logs just in the format they need, without having to open the log files,
> parsing the lines to rewrite in a different format as is done currently.

Yes, I have been pinged about that, which is why there are still cases
for my out-of-core extension jsonlog that uses the elog hook.

> I think this would be a relatively easy patch to do.  Opinions?

The postmaster goes through a couple of loops with the fd to open for
the default format, that the syslogger inherits from the postmaster,
and I am pretty sure that there are a couple of code paths around the
postmaster startup that can be tricky to reason about.

Making the new parameter PGC_POSTMASTER makes things easier to handle,
still the postmaster generates a couple of LOG entries and redirects
them to stderr before loading any GUC values, which would mean that we
cannot make sure that all the logs are valid JSON objects.  If we want
to be 100% waterproof here, we may want to track down the format to
use by default with a mean different than a GUC for the postmaster
startup?  A file holding this information in the root of the data
folder would be one way.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Add jsonlog log_destination for JSON server logs
Next
From: Andres Freund
Date:
Subject: Re: generic plans and "initial" pruning