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

Applied.

---------------------------------------------------------------------------

On Mon, Oct 15, 2012 at 02:22:33PM -0400, Bruce Momjian wrote:
> 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. +
> 
> 
> -- 
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers

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