Re: Log timestamps at higher resolution

2018-10-25 Thread Alvaro Herrera
On 2018-Oct-25, David Fetter wrote: > > 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 w

Re: Log timestamps at higher resolution

2018-10-25 Thread David Fetter
On Thu, Oct 25, 2018 at 01:00:08PM +1300, David Rowley wrote: > On 25 October 2018 at 11:25, David Fetter 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 incl

Re: Log timestamps at higher resolution

2018-10-24 Thread Michael Paquier
On Thu, Oct 25, 2018 at 01:00:08PM +1300, David Rowley wrote: > On 25 October 2018 at 11:25, David Fetter wrote: >> 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 th

Re: Log timestamps at higher resolution

2018-10-24 Thread David Rowley
On 25 October 2018 at 11:25, David Fetter 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 th

Re: Log timestamps at higher resolution

2018-10-24 Thread David Fetter
On Wed, Oct 24, 2018 at 03:17:09PM +0100, Tom Lane wrote: > Alvaro Herrera writes: > > On 2018-Oct-24, David Fetter wrote: > >> For another, having separate letter rather than number modifiers as > >> printf("%03d") does, is just lousy API design. > > > I don't think the API is lousy as all that,

Re: Log timestamps at higher resolution

2018-10-24 Thread David Fetter
On Wed, Oct 24, 2018 at 11:10:02AM +0100, Tom Lane wrote: > David Fetter writes: > > On Wed, Oct 24, 2018 at 08:00:24AM +1300, Thomas Munro wrote: > >> On Wed, Oct 24, 2018 at 7:51 AM David Fetter wrote: > >>> Per gripes I've been hearing with increasing frequency, please find > >>> attached a pa

Re: Log timestamps at higher resolution

2018-10-24 Thread Tom Lane
Alvaro Herrera writes: > On 2018-Oct-24, David Fetter wrote: >> For another, having separate letter rather than number modifiers as >> printf("%03d") does, is just lousy API design. > I don't think the API is lousy as all that, but a further improvement to > allow a precision specifier might be a

Re: Log timestamps at higher resolution

2018-10-24 Thread Alvaro Herrera
On 2018-Oct-24, David Fetter wrote: > For another, having separate letter rather than number modifiers as > printf("%03d") does, is just lousy API design. I don't think the API is lousy as all that, but a further improvement to allow a precision specifier might be a worthy feature addition -- say

Re: Log timestamps at higher resolution

2018-10-24 Thread Tom Lane
David Fetter writes: > On Wed, Oct 24, 2018 at 08:00:24AM +1300, Thomas Munro wrote: >> On Wed, Oct 24, 2018 at 7:51 AM David Fetter wrote: >>> Per gripes I've been hearing with increasing frequency, please find >>> attached a patch that implements $Subject. It's microsecond resolution >>> becaus

Re: Log timestamps at higher resolution

2018-10-23 Thread David Fetter
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 privat

Re: Log timestamps at higher resolution

2018-10-23 Thread Michael Paquier
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 no

Re: Log timestamps at higher resolution

2018-10-23 Thread David Fetter
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 wrote: > > > > Per gripes I've been hearing with increasing frequency, pleas

Re: Log timestamps at higher resolution

2018-10-23 Thread Alvaro Herrera
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 wrote: > > > Per gripes I've been hearing with increasing frequency, please find > > > attached a patch that implements $Subject. It's microsecond r

Re: Log timestamps at higher resolution

2018-10-23 Thread David Fetter
On Wed, Oct 24, 2018 at 08:00:24AM +1300, Thomas Munro wrote: > On Wed, Oct 24, 2018 at 7:51 AM David Fetter 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,

Re: Log timestamps at higher resolution

2018-10-23 Thread Thomas Munro
On Wed, Oct 24, 2018 at 7:51 AM David Fetter 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.

Log timestamps at higher resolution

2018-10-23 Thread David Fetter
Folks, 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. Best, David. -- David Fetter http://fetter.org/ P