Re: Proposal: Adding json logging

Поиск
Список
Период
Сортировка
От David Arnold
Тема Re: Proposal: Adding json logging
Дата
Msg-id CAH6vsWKu6jLPzi2pDmdn2v4KJ1UzMuBjJAXWN_QE3uvRRBWs0w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Proposal: Adding json logging  (Christophe Pettus <xof@thebuild.com>)
Список 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@thebuild.com>) escribió:

> On Apr 18, 2018, at 11:59, Robert Haas <robertmhaas@gmail.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@thebuild.com

--
XOE SolutionsDAVID ARNOLD
Gerente General
xoe.solutions
dar@xoe.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.

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Query is over 2x slower with jit=on
Следующее
От: Tom Lane
Дата:
Сообщение: Re: reloption to prevent VACUUM from truncating empty pages at the end of relation