From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PATCH: numeric timestamp in log_line_prefix |
Date: | 2015-09-07 21:15:57 |
Message-ID: | 1441660557.10365.28.camel@jeff-desktop |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> I wonder about this separate gettimeofday() call. We already have
> formatted_log_time which is used for CSV logs and freeform log lines
> (stderr/syslog); if we introduce a separate gettimeofday() call here,
> and the user has %n in freeform log and CSV logging is active, the
> timings will diverge occasionally.
>
> Maybe I'm worrying over nothing, because really what use case is there
> for having the two log formats enabled at the same time? Yet somebody
> went some lengths to ensure they are consistent; I think we should do
> likewise here.
We now have three time-related options[1]: t, m, and n; and they each
acquire the time independently. Are you suggesting that we make all
three consistent, or only m and n?
The cleanest fix would be for the global variable to only hold the
timeval, and then format it once for the CSV log (always 'm' format) and
once for the regular log ('m', 'n', or 't'). If the regular log uses
'm', that would be some wasted cycles formatting it the same way twice.
Is it worth a little extra ugliness to cache both the timeval and the
formatted string?
Regards,
Jeff Davis
[1] As of minutes ago, after I missed your message by a few minutes.
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2015-09-07 21:28:03 | Re: PATCH: numeric timestamp in log_line_prefix |
Previous Message | Petr Jelinek | 2015-09-07 21:14:34 | Re: creating extension including dependencies |