Re: Log timestamps at higher resolution

From: David Fetter <david(at)fetter(dot)org>
To: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Log timestamps at higher resolution
Date: 2018-10-25 16:04:22
Message-ID: 20181025160422.GA12677@fetter.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Oct 25, 2018 at 01:00:08PM +1300, David Rowley wrote:
> On 25 October 2018 at 11:25, David Fetter <david(at)fetter(dot)org> wrote:
> > Digging a teensy bit deeper, I noticed that there's already a
> > "padding" (space padding, if I understand correctly) system for parts
> > of the log_line_prefix specification including %m. Did we get painted
> > into a corner here back in 9.4, when the padding feature was added?
> > https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=4334639f4bb9fb88c13b8dd5faca22b207248504
>
> I'm not sure "painted into a corner" is the right way to think about
> this.

Excellent!

> Numerics immediately followed by the '%' are simply already used by
> the space padding feature. If you want some other modifier then
> you'll need to invent some other syntax to identify that. It looks
> like using a '.' after the '%' was mentioned by Alvaro.
>
> I think the best way to implement this is to rename
> process_log_prefix_padding into process_log_prefix_modifiers and add
> an "int *precision" variable and add some code to parse and populate
> that based on if there's a '.' found in the prefix. Then in
> log_line_prefix() just take into account the precision for any
> prefix variable that it should apply to. So, %s likely should be
> altered too, although that might require some additional code to
> NULLify the string if the server config is reloaded, or perhaps you
> can just remember how much precision that string was made with and
> only rebuild it if the required precision changes. We don't seem to
> have any other floating point type prefix variables, so I don't
> think any of the others need to be altered.

Thanks for the detailed roadmap on this.

> > Strangely, there were no tests that came with that either. David,
> > did you mean to expand it past space padding, or...?
>
> Unsure what infrastructure existed then for testing this.
>
> I didn't intend to add anything else later. I don't think we have
> any variables that zero padding would be that useful for, but maybe
> someone might want to zero pad their pids or xids... ?

They might, so I'll either put in a comment where that would go or
just implement it.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2018-10-25 16:22:50 Re: Log timestamps at higher resolution
Previous Message Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?= 2018-10-25 16:02:32 Re: [PATCH] Tab complete EXECUTE FUNCTION for CREATE (EVENT) TRIGGER