Re: Fix for log_line_prefix and session display - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Fix for log_line_prefix and session display
Date
Msg-id 20121015182233.GB7494@momjian.us
Whole thread Raw
In response to Re: Fix for log_line_prefix and session display  ("Albe Laurenz" <laurenz.albe@wien.gv.at>)
Responses Re: Fix for log_line_prefix and session display  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
On Mon, Oct 15, 2012 at 10:01:29AM +0200, Albe Laurenz wrote:
> Bruce Momjian wrote:
> > Currently, our session id, displayed by log_line_prefix and CSV
> output,
> > is made up of the session start time epoch seconds and the process id.
> > The problem is that the printf mask is currently %lx.%x, causing a
> > process id less than 4096 to not display a full four hex digits after
> > the decimal point.  I think this is confusing because the number .423
> > appears higher than .1423, though it is not.  Here is what our current
> > output looks like with log_line_prefix="%c: ":
> > 
> >     50785b3e.7ff9: ERROR:  syntax error at or near "test" at
> character 1
> >     50785b3e.7ff9: STATEMENT:  test
> >     50785b3e.144: ERROR:  syntax error at or near "test" at
> character 1
> >     50785b3e.144: STATEMENT:  test
> > 
> > With my fix, here is the updated output:
> > 
> >     507864d3.7ff2: ERROR:  syntax error at or near "test" at
> character 1
> >     507864d3.7ff2: STATEMENT:  test
> >     507864d3.013d: ERROR:  syntax error at or near "test" at
> character 1
> >     507864d3.013d: STATEMENT:  test
> > 
> > Patch attached.
> 
> Do you think that anybody wants to apply a linear ordering on
> the second part of the session ID?  If you need the pid, you
> can use %p.
> 
> I would say that this change makes sense if it causes disturbance
> that the part after the period can be than 4 characters long
> (it did not disturb me when I wrote a log file parser).
> 
> If that need is not urgent enough, maybe it would be better to
> preserve the current behaviour in the (unlikely) event that somebody
> relies on it.

I don't think anyone is picking apart the session id, but I do think the
current output is confusing because the session id string length is
pretty variable.  Anyone who is parsing the current session id will
easily be able to parse the more consistent output.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Deprecating Hash Indexes
Next
From: Andres Freund
Date:
Subject: Re: [RFC][PATCH] wal decoding, attempt #2 - Design Documents (really attached)