Re: Proposal: Adding json logging

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Christophe Pettus <xof(at)thebuild(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 18:59:26
Message-ID: CA+TgmoYWA0CHO6WLPnV2_a6nmD4tX7mKTifDsMktVBfG4TM0zw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Apr 15, 2018 at 1:07 PM, Christophe Pettus <xof(at)thebuild(dot)com> wrote:
>> On Apr 15, 2018, at 09:51, David Arnold <dar(at)xoe(dot)solutions> wrote:
>> 1. Throughout this vivid discussion a good portion of support has already been manifested for the need of a more structured (machine readable) logging format. There has been no substantial objection to this need.
>
> I'm afraid I don't see that. While it's true that as a standard, CSV is relatively ill-defined, as a practical matter in PostgreSQL it is very easy to write code that parses .csv format.

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. For example, and as has been
discussed on this thread, if you have a system that is consuming the
logs that already knows how to parse JSON but does not know how to
parse CSV, then you will find the JSON format to be convenient.

For the record, I'm tentatively in favor of including something like
this in contrib. I think it's useful to have more examples of how to
use our existing hooks in contrib, and I think this is useful on
principle.

I am a little concerned about this bit from the README, though:

====
Note that logging_collector should be enabled in postgresql.conf to
ensure consistent log outputs. As JSON strings are longer than normal
logs generated by PostgreSQL, this module increases the odds of malformed
log entries.
====

I'm not sure I understand the issue, but I don't like malformed log entries.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-04-18 19:03:57 Re: Truncation failure in autovacuum results in data corruption (duplicate keys)
Previous Message Tom Lane 2018-04-18 18:34:03 Re: Deadlock in multiple CIC.