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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers