Re: Log timestamps at higher resolution

On Tue, Oct 23, 2018 at 04:14:50PM -0300, Alvaro Herrera wrote:
> On 2018-Oct-23, David Fetter wrote:
>
> > On Wed, Oct 24, 2018 at 08:00:24AM +1300, Thomas Munro wrote:
> > > On Wed, Oct 24, 2018 at 7:51 AM David Fetter <david(at)fetter(dot)org> wrote:
> > > > Per gripes I've been hearing with increasing frequency, please find
> > > > attached a patch that implements $Subject. It's microsecond resolution
> > > > because at least at the moment, nanosecond resolution doesn't appear
> > > > to be helpful in this context.
> > >
> > > Wouldn't you want to choose a new letter or some other way to make
> > > existing format control strings do what they always did?
> >
> > I hadn't because I'd looked at the existing format as merely buggy in
> > lacking precision, although I guess with really fussy log processors,
> > this change could break things.
> >
> > Have you seen processors like that in the wild?
>
> pgbadger does this:
> '%m' => [('t_mtimestamp', '(\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2})\.\d+(?: [A-Z\+\-\d]{3,6})?')], # timestamp with milliseconds
>
> which should cope with however many digits there are (\d+).
> But I would expect others to be less forgiving ...

That's an interesting point. pgbadger is the only one I recall using
that's still maintained. Which others would it be useful to test?

Also, do we have tests--or at least ideas of how to
test--functionality relating to logging? I was a little bit taken
aback by the fact that `make check-world` passed after the change.

Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate