Re: Add jsonlog log_destination for JSON server logs

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Sehrope Sarkuni <sehrope(at)jackdb(dot)com>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, david(at)fetter(dot)org
Subject: Re: Add jsonlog log_destination for JSON server logs
Date: 2021-09-01 00:43:50
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Tue, Aug 31, 2021 at 11:34:56AM -0400, Sehrope Sarkuni wrote:
> The second commit adds a TAP test for log_destination "csvlog". This was
> done to both confirm that the previous change didn't break anything and as
> a skeleton for the test in the next commit.

+note "Before sleep";
+note "Before rotate";
+note "After rotate";

Do you really need a rotation of the log files here? Wouldn't it be
better to grab the position of the current log file with a fixed log
file name, and then slurp the file from this position with your
expected output? That would make the test faster, as well.

> The third commit adds the new log_destination "jsonlog". The output format
> is one line per entry with the top level output being a JSON object keyed
> with the log fields. Newlines in the output fields are escaped as \n so the
> output file has exactly one line per log entry. It also includes a new test
> for verifying the JSON output with some basic regex checks (similar to the
> csvlog test).

+ * Write logs in json format.
+ */
+static void
+write_jsonlog(ErrorData *edata)
Rather than making elog.c larger, I think that we should try to split
that into more files. Why not refactoring out the CSV part first?
You could just call that csvlog.c, then create a new jsonlog.c for the
meat of the patch.

The list of fields is not up to date. At quick glance, you are
- backend type.
- leader PID.
- query ID.
- Session start timestamp (?)

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message 2021-09-01 00:52:05 Re: archive status ".ready" files may be created too early
Previous Message Michael Paquier 2021-09-01 00:28:02 Re: Proposal: More structured logging