From: "Tom Lane" <[EMAIL PROTECTED]>
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).
About patch, it was only a thing for one solution. I thought that a next discussion
was required for the problem which elog has.
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.
Ah yes, I agreed on the worries about the change.
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
I understand the essence which you say. Then, I think that gmtime is an ideal
there. localtime also takes summer time into consideration. It changes and
sometimes falls unconsciously. Furthermore, a tzname can't be expressed
by the present elog....
Moreover, how about relocating datacenter to New York from the loss Angelus?
The log is continued.... database log is an audit item. Recently, it is more
important than a response. And it is used secondarily.
What does a CSV output become in the latest feature?
I am not good at explanation. However, I desire what you understand.
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend