Re: Finer grain log timestamps

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

In response to

Responses

Browse pgsql-hackers by date

  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