Re: Log timestamps at higher resolution - Mailing list pgsql-hackers

From David Fetter
Subject Re: Log timestamps at higher resolution
Date
Msg-id 20181025160422.GA12677@fetter.org
Whole thread Raw
In response to Re: Log timestamps at higher resolution  (David Rowley <david.rowley@2ndquadrant.com>)
Responses Re: Log timestamps at higher resolution
List 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@fetter.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


pgsql-hackers by date:

Previous
From: ilmari@ilmari.org (Dagfinn Ilmari Mannsåker)
Date:
Subject: Re: [PATCH] Tab complete EXECUTE FUNCTION for CREATE (EVENT) TRIGGER
Next
From: Alvaro Herrera
Date:
Subject: Re: Log timestamps at higher resolution