Re: PATCH: numeric timestamp in log_line_prefix

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.

In response to

Responses

Browse pgsql-hackers by date

  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