hubert depesz lubaczewski wrote:
> When I enabled normal stderr logging, with absurdly full
> log_line_prefix, I got this:
> a[psql] u[depesz] d[depesz] r[[local]] h[[local]] p[15444] t[2012-09-13 21:49:37 CEST] m[2012-09-13
> 21:49:37.840 CEST] i[SELECT] e[00000] c[505238d0.3c54] l[4] s[2012-09-13 21:49:36 CEST] v[2/2] x[0]
> CONTEXT: SQL statement "SELECT b()"
> PL/pgSQL function a() line 1 at PERFORM
> same function call, with syslog:
> Sep 13 21:53:31 h3po4 postgres[16156]: [4-2] a[psql] u[depesz] d[depesz] r[[local]] h[[local]]
> p[16156] t[2012-09-13 21:53:31 CEST] m[2012-09-13 21:53:31.852 CEST] i[SELECT] e[00000]
> c[505239bb.3f1c] l[4] s[2012-09-13 21:53:31 CEST] v[2/4] x[0] CONTEXT: SQL statement "SELECT b()"
> Sep 13 21:53:31 h3po4 postgres[16156]: [4-3] #011PL/pgSQL function a() line 1 at PERFORM
> Please note that the 3rd line in both examples has leading tab - either
> literal tab in case of stderr log, or #011 in case of syslog.
>
> But with csvlog, I got something different:
> 2012-09-13 21:51:12.642 CEST,"depesz","depesz",15673,"[local]",5052392f.3d39,3,"SELECT",2012-09-13
> 21:51:11 CEST,2/2,0,LOG,00000,"[logged line]",,,,,"SQL statement ""SELECT b()""
> PL/pgSQL function a() line 1 at PERFORM","select a();",,,"psql"
> There is no leading tab on the 2nd line. Why? Is it intentional, or just
> an omission?
I think that the current behaviour makes sense.
The actual context message did not have a tab in it, just a line break.
In CSV you can leave it like that, because the quoting will make it
clear that the line break is not the start of a new log entry.
In the other two cases a tab is added to distinguish a line break
(or new message for syslog) that starts a new log entry from a
line break that is part of a log entry.
This makes automatic parsing of log files possible:
if a line starts with a tab, it is a continuation line.
The tab itself is not part of the message.
Yours,
Laurenz Albe