Hi.
From: "Tom Lane" <tgl@sss.pgh.pa.us>
> Gregory Stark <stark@enterprisedb.com> writes:
>> "Tom Lane" <tgl@sss.pgh.pa.us> 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
> printout.
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.
Regards,
Hiroshi Saito
