Re: Proposal: Adding json logging

From: "Daniel Verite" <daniel(at)manitou-mail(dot)org>
To: "David Arnold" <dar(at)xoe(dot)solutions>
Cc: "Christophe Pettus" <xof(at)thebuild(dot)com>,"John W Higgins" <wishdev(at)gmail(dot)com>,pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Proposal: Adding json logging
Date: 2018-04-16 18:27:59
Message-ID: 6d0a1374-13af-40ad-aed9-93fb8bd087bb@manitou-mail.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

David Arnold wrote:

> Not claiming this assumption does imply parsing of a *rolling* set
> of log lines with *previously unkown cardinality*. That's expensive
> on computing resources. I don't have actual numbers, but it doesn't
> seem too far fetched, neither.
> I filed a question to the author of fluent-bit to that extend which
> you can consult here:
> https://github.com/fluent/fluent-bit/issues/564 Let's see what
> Eduardo has to inform us about this...

fluent-bit does not appear to support CSV, as mentioned in
https://github.com/fluent/fluent-bit/issues/459
which got flagged as an enhancement request some time ago.

In CSV a line break inside a field is easy to process for
a parser, because (per https://tools.ietf.org/html/rfc4180):

"Fields containing line breaks (CRLF), double quotes, and commas
should be enclosed in double-quotes"

So there is no look ahead to do. In a character-by-character loop,
when encountering a line break, either the current field did not
start with a double quote and the line break is part of the content, or it
did
start with a double quote and the line break ends the current record.

What doesn't quite work is to parse CSV with a regex, it's
discussed in some detail here for instance:
https://softwareengineering.stackexchange.com/questions/166454/can-the-csv-format-be-defined-by-a-regex

Best regards,
--
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Guilherme Pereira 2018-04-16 18:40:48 Re: very slow queries when max_parallel_workers_per_gather is higher than zero
Previous Message Alexander Lakhin 2018-04-16 17:12:45 Re: Overcoming SELECT ... FOR UPDATE permission restrictions