From: | Christoph Berg <myon(at)debian(dot)org> |
---|---|
To: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
Cc: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Andrew Dunstan <andrew(at)dunslane(dot)net> |
Subject: | Re: Set log_line_prefix and application name in test drivers |
Date: | 2016-08-27 19:50:40 |
Message-ID: | 20160827195040.dytftqa2wejuoqgi@msg.df7cb.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Re: Fabien COELHO 2016-08-26 <alpine(dot)DEB(dot)2(dot)20(dot)1608261620260(dot)7102(at)lancre>
> So I would suggest something like the following, which is also a little bit
> more compact:
>
> log_line_prefix = '%m [%p:%l] %q%a '
>
> If you want to keep something with %a, maybe parentheses?
>
> Finally I'm wondering also whether a timestamp since the server has started
> (which does not exists) would be more useful for a "make check", or at
> default maybe %n?
I've always been wondering why we don't set a log_line_prefix by
default. Logs without timestamps and (pid or session id or equivalent)
are useless. Of course in practise the log_line_prefix needs to be
different depending on the log_destination (syslog adds its own
timestamps, ...), but the current default of '' doesn't help anyone.
The above looks quite similar to what the Debian packages have been
setting as their default for some time, with standard stderr logging:
log_line_prefix = '%t [%p-%l] %q%u(at)%d '
People who want a different log channel need to touch the config
anyway and can update log_line_prefix as they go.
The concrete value to be used needs to be discussed, but I think we'd
end up with something like '%m [%p:%l] ' plus maybe some suffix.
Christoph
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-08-27 19:50:49 | Re: Bogus sizing parameters in some AllocSetContextCreate calls |
Previous Message | Andres Freund | 2016-08-27 19:47:27 | Re: Bogus sizing parameters in some AllocSetContextCreate calls |