From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | David Fetter <david(at)fetter(dot)org> |
Cc: | PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCH] Log CSV by default |
Date: | 2018-11-30 20:15:49 |
Message-ID: | 20181130201549.l65algxurcjp5yoc@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
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. Yes, a conversion into
something more readable can be done programatically, but that's another
step before analyzing a problem. And besides, a lot of log fragments are
embedded in email, screenshotted etc.
Secondarily, csvlog doesn't contain all the interesting information.
Thirdly, it often increases the log volume noticably.
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).
- Andres
From | Date | Subject | |
---|---|---|---|
Next Message | Dmitry Dolgov | 2018-11-30 20:43:41 | Re: pg_dumpall --exclude-database option |
Previous Message | Dmitry Dolgov | 2018-11-30 20:08:14 | Re: Range phrase operator in tsquery |