Re: Proposal: Adding json logging

From: Christophe Pettus <xof(at)thebuild(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: David Arnold <dar(at)xoe(dot)solutions>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Proposal: Adding json logging
Date: 2018-04-18 19:10:47
Message-ID: 50106A1D-E74A-430E-AA16-CBDA52CBD46C@thebuild.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


> On Apr 18, 2018, at 11:59, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> I'm not sure exactly how you intended to this comment, but it seems to
> me that whether CSV is ease or hard to parse, somebody might
> legitimately find JSON more convenient.

Of course. The specific comment I was replying to made a couple of jumps that I wanted to unwind: The first is that we don't have a machine-readable format for PostgreSQL (we do, CSV), and that there was "no substantial objection to this need."

If the requirement is: "There is a large class of log analysis tool out there that has trouble with multiline formats and we should be good ecosystem players," that's fine. (I'm a bit sour about the number of tools being written with one-line-per-event baked into them and whose solution to any other format is "use regex," but that's neither here nor there, I suppose.)

My primary objection to creating new output formats is that it creates an implicit burden on downstream tools to adopt them. For example, a log of query analysis tools don't yet process JSON-format plans, and they've been around for a while. By introducing a new format in core (which was the starting proposal), we're essentially telling all the tools (such as pgbadger) that might absorb them that we expect them to adopt that too.

> For the record, I'm tentatively in favor of including something like
> this in contrib.

I'm much less fussed by this in contrib/ (with the same concern you noted), at minimum as an example of how to do logging in other formats.

--
-- Christophe Pettus
xof(at)thebuild(dot)com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2018-04-18 19:16:35 Re: Query is over 2x slower with jit=on
Previous Message Tom Lane 2018-04-18 19:03:57 Re: Truncation failure in autovacuum results in data corruption (duplicate keys)