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. +
Attachments:
prefix.difftext/x-diff; charset=us-asciiDownload
diff --git a/src/backend/utils/error/elog.c b/src/backend/utils/error/elog.c
new file mode 100644
index a40b343..68b7ab3
*** a/src/backend/utils/error/elog.c
--- b/src/backend/utils/error/elog.c
*************** log_line_prefix(StringInfo buf, ErrorDat
*** 1970,1976 ****
}
break;
case 'c':
! appendStringInfo(buf, "%lx.%x", (long) (MyStartTime), MyProcPid);
break;
case 'p':
appendStringInfo(buf, "%d", MyProcPid);
--- 1970,1976 ----
}
break;
case 'c':
! appendStringInfo(buf, "%lx.%04x", (long) (MyStartTime), MyProcPid);
break;
case 'p':
appendStringInfo(buf, "%d", MyProcPid);
*************** write_csvlog(ErrorData *edata)
*** 2149,2155 ****
appendStringInfoChar(&buf, ',');
/* session id */
! appendStringInfo(&buf, "%lx.%x", (long) MyStartTime, MyProcPid);
appendStringInfoChar(&buf, ',');
/* Line number */
--- 2149,2155 ----
appendStringInfoChar(&buf, ',');
/* session id */
! appendStringInfo(&buf, "%lx.%04x", (long) MyStartTime, MyProcPid);
appendStringInfoChar(&buf, ',');
/* Line number */
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" atcharacter 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" atcharacter 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" atcharacter 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" atcharacter 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. +