Thread: Fix for log_line_prefix and session display
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.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
Attachment
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. Yours, Laurenz Albe
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. +
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. +