Re: PATCH: numeric timestamp in log_line_prefix

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
Cc: 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 19:27:19
Message-ID: 20150907192719.GS2912@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> + case 'n':
> + {
> + struct timeval tv;
> + char strfbuf[128];
> +
> + gettimeofday(&tv, NULL);
> + sprintf(strfbuf, "%ld.%03d", tv.tv_sec, (int)(tv.tv_usec / 1000));
> +
> + if (padding != 0)
> + appendStringInfo(buf, "%*s", padding, strfbuf);
> + else
> + appendStringInfoString(buf, strfbuf);
> + }
> + break;

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.

I'm happy to be outvoted on this, so consider this a -0.5 for this
particular implementation.

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Petr Jelinek 2015-09-07 19:28:07 Re: creating extension including dependencies
Previous Message Andres Freund 2015-09-07 19:24:27 Re: creating extension including dependencies