Re: Proposal: Adding json logging

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

Excellent phrasing (thanks to Christophe!): "There is a large class of log
analysis tool out there that has trouble with multiline formats and we
should be good ecosystem players"

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

This would be a very well balanced compromise, almost every distribution
flavour also packages contrib so installing contrib and loading such module
as a convenient pre-packaged shared library would just be an excellent
solution to the big majority of Postgres users.

Now we are moving to the solutions space :) I wanted to wait this week,
though, to give sufficient time to comment on all aspects and would do
another wrap-up next weekend. This suggestion would definitely be part of
it.

El mié., 18 abr. 2018 a las 14:10, Christophe Pettus (<xof(at)thebuild(dot)com>)
escribió:

>
> > 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
>
> --
[image: XOE Solutions] <http://xoe.solutions/> DAVID ARNOLD
Gerente General
xoe.solutions
dar(at)xoe(dot)solutions
+57 (315) 304 13 68
*Confidentiality Note: * This email may contain confidential and/or private
information. If you received this email in error please delete and notify
sender.
*Environmental Consideration: * Please avoid printing this email on paper,
unless really necessary.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-04-18 19:33:08 Re: reloption to prevent VACUUM from truncating empty pages at the end of relation
Previous Message Andres Freund 2018-04-18 19:29:22 Re: Query is over 2x slower with jit=on