Re: [PATCH] Log CSV by default

From: Arkhena <Arkhena(at)gmail(dot)com>
To: david(at)fetter(dot)org
Cc: tgl(at)sss(dot)pgh(dot)pa(dot)us, andres(at)anarazel(dot)de, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Log CSV by default
Date: 2018-12-02 10:20:59
Message-ID: CAB_COdhpb-OmE=FgjqLHgmQJ4x=w3LcWPTAGYGAS-V9edG3NHg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi all,

> Also, in addition to the objections you noted, there's the problem that
> this change requires changing logging_collector to default to "on".
> That's an *enormous* compatibility break, because of the effects on
> where the log output goes.
>

As a consultant with so many customers that simply install Postgres "out of
the box", I think that changing log_destination to 'csvlog' and
logging_collector to 'on' needs changing at least log_truncate_on_rotation
(but certainly also log_filename and log_rotation_age) if we don't want my
customers to run out of space sooner or later.

So, that's a "-1" for me to change the log_destination default to 'csvlog'.

Personally, I use one of my colleague's python script that "change" the
standard text output to csv (and even create the table and insert rows in
it by connecting to my database), so I can use my SQL queries to perform
log analyzes.
So I think the idea of a 'pg_logparse' is wonderfull.

Cheers,

Lætitia

Le sam. 1 déc. 2018 à 01:03, David Fetter <david(at)fetter(dot)org> a écrit :

> On Fri, Nov 30, 2018 at 04:55:30PM -0500, Tom Lane wrote:
> > Andres Freund <andres(at)anarazel(dot)de> writes:
> > > On 2018-11-30 19:53:18 +0100, David Fetter wrote:
> > >> This makes it much simpler for computers to use the logs while not
> > >> making it excessively difficult for humans to use them.
> >
> > > While perhaps not excessively so, I think it increases the difficulty
> > > sufficiently that I'm against such a proposal.
> >
> > I don't like this either. People who prefer CSV format can select it
> > trivially. Those who don't are going to be annoyed at us for changing
> > behavior that's stood for many years.
> >
> > Also, in addition to the objections you noted, there's the problem that
> > this change requires changing logging_collector to default to "on".
> > That's an *enormous* compatibility break, because of the effects on
> > where the log output goes. Not to mention having performance impacts
> > that can be significant.
> >
> > I think we should reject this out of hand.
>
> It's been far too long since I got one of these!
>
> > > I think having a bin/pg_logparse tool that can parse postgres' config
> > > file and attempt to parse the log contents in whatever format they are
> > > would be much much more useful. Obviously not every log_line_prefix can
> > > be parsed unambiguously, but a lot of formats can, and a lot more
> > > formats can be made unambiguous (e.g. adding escape logic to
> application
> > > name logging would be very useful).
> >
> > Yeah, it might be possible to make some progress in those directions.
>
> So application names need better handling, and possibly reviews for
> security considerations, and pg_logparse ?
>
> OK.
>
> Best,
> David.
> --
> David Fetter <david(at)fetter(dot)org> http://fetter.org/
> Phone: +1 415 235 3778
>
> Remember to vote!
> Consider donating to Postgres: http://www.postgresql.org/about/donate
>
>

--
Adoptez l'éco-attitude
N'imprimez ce mail que si c'est vraiment nécessaire

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Oleg Bartunov 2018-12-02 10:26:35 Re: on or true
Previous Message legrand legrand 2018-12-02 09:22:07 Re: {PROPOSAL] add session information column to pg_stat_statements