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.
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 |