Jeff Davis wrote:
> > 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?
I noticed %t, but I don't think we care since the precision is so poor.
Making m and n work in unison seems enough. I think it would be
reasonably simple to handle %t in the same way, but I'm not sure we
care.
(TBH I question that %t has any usefulness at all. Maybe we should
phase it out ...)
> 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?
I think the extra ugliness is warranted, since it's not THAT much
additional ugliness, and not doing it could be considered a regression;
apparently strftime can be slower even than snprintf, so doing it twice
per log message might be excessive overhead.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
