Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> I don't think it's an acceptable change in either place. People who
>> want to see UTC in their logs can start the postmaster in UTC. Those
>> who are accustomed to seeing local time will squawk.
> It would probably make sense to use UTC in the CSV logs since they're intended
> to be machine readable. Whatever program is used to read them can handle
> displaying the timestamps in the appropriate timezone for user's consumption.
I don't think we really want to pay for formatting the timestamp twice
(the existing patch goes out of its way to avoid that IIRC).
Thinking back, the major reason why we use platform strftime() here is
to ensure that all backends will print log entries in the same timezone
regardless of session settings of the TimeZone GUC. That decision was
taken a long time ago, before we had the modern GUC infrastructure,
and also before we had pgtz infrastructure that could efficiently handle
conversions in multiple zones at once. Perhaps it would make sense to
invent a system-wide (PGC_SIGHUP) variable "log_timezone" and use
pg_strftime() with that setting to format timestamps for the log.
That would eliminate platform variability of all kinds, not just the
immediate Windows issue, and it might gain performance on some platforms
(glibc in particular has a bad habit of doing a syscall for every
strftime call). The only downside I can think of is that problems with
the log_timezone setting could lead to recursive errors and eventual
PANIC, but that's true of almost anything that goes wrong during error
printout.
Comments?
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
