Re: [PATCH] Log CSV by default
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@fetter.org> a écrit :
On Fri, Nov 30, 2018 at 04:55:30PM -0500, Tom Lane wrote:
> Andres Freund <andres@anarazel.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
N'imprimez ce mail que si c'est vraiment nécessaire
В списке pgsql-hackers по дате отправления:
Предыдущее
От: legrand legrandДата:
Сообщение: Re: {PROPOSAL] add session information column to pg_stat_statements