Re: Log timestamps at higher resolution

On Wed, Oct 24, 2018 at 08:46:47AM +0900, Michael Paquier wrote:
> On Wed, Oct 24, 2018 at 12:11:18AM +0200, David Fetter wrote:
> > 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?
>
> There could be private solutions as well. My take is that we should use
> separate letters and not change the existing ones or we'll get
> complains.

I believe that the utility of having finer time resolution outweighs
the inconvenience of changing processing systems, to the extent that
that's a consideration.

Adding yet more random letter options to log_line_prefix isn't free
either.

For one thing, there are a limited number of single-letter options we
can use, and we need to make sure they can continue to make sense, or
at least have reasonably consistent meanings.

For another, having separate letter rather than number modifiers as
printf("%03d") does, is just lousy API design. Baroque is OK for
music if you're in the mood, but not so great for log line prefix
format codes. If we do go the number option route, we can only not
break people's fussy parsers by having a default format of length 3, a
decision which will get harder and harder to justify as time goes on.

I'm happy to code up a number option if that's what people want, but
that'll break things the same way the current patch does, modulo The
Inexplicable Decision To Default To Three Decimal Places, which code
archaeologists will love and system implementers will hate.

> > 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.
>
> This requires server-level changes where a TAP test is usually adapted,
> and there is no test for logging yet.

Is that worth a separate patch?

I suspect that as things Cloud™ (a.k.a. Renting Other People's Data
Centers) get even more popular, we'll want to improve our logging
game, and that will sooner rather than later have features complicated
enough to be worth testing.

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