From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | David Fetter <david(at)fetter(dot)org>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Finer grain log timestamps |
Date: | 2022-06-13 20:22:42 |
Message-ID: | 3920623.1655151762@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Sun, May 8, 2022 at 4:45 PM David Fetter <david(at)fetter(dot)org> wrote:
>> Please find attached a patch to change the sub-second granularity of
>> log timestamps from milliseconds to microseconds.
> Why is this a good idea?
I can imagine that some people would have a use for microsecond
resolution in log files, and I can also imagine that as machines
get faster more people will want that. As against that, this
will bloat log files by a non-microscopic amount, and it's pretty
likely to break some log-scanning tools too. It's unclear to me
that that's a tradeoff we should force on everyone.
I think a proposal less likely to have push-back would be to invent
a different log_line_prefix %-escape to produce microseconds.
Sadly, "%u" is already taken, but perhaps we could use "%U"?
A different line of thought is to extend %t to provide a precision
field a la sprintf, so that for example "%.3t" is equivalent to
"%m" and "%.6t" does what David wants, and we won't have to
search for a new escape letter when the day arrives that
somebody wants nanosecond resolution. The same could be done
with %n, avoiding the need to find a different escape letter
for that.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2022-06-13 20:24:09 | Re: pltcl crash on recent macOS |
Previous Message | Peter Eisentraut | 2022-06-13 20:21:17 | Re: pltcl crash on recent macOS |