Fellow hackers,
Back in August I submitted a patch that essentially did 2 things:
. explicitly logged the end of a client connection, including the
connection's elapsed time, enabled by a config variable called
"log_session_end", and
. provided for tagging all of a sessions log lines using a printf-style
format string, recognizing the escape sequences %U = username and %D =
databasename, and enabled via a config variable called "log_line_format".
This was done after some discussion on the hackers list - see mailing
list archives around the beginning of August under the heading "logging
stuff" if you are interested. Back then most of the discussion was
around the names and formats of the GUC variables. The consensus seemed
to be that we should not roll the pid and timestamp variables up into a
single variable. In private and public discussion Bruce has now raised
this possibility again. However, having reviewed the matter I have again
come to the conclusion that this is not a good idea for 2 reasons:
. syslog already does timestamp and pid logging, so if we rolled these
up we'd have to add in extra processing just for the syslog case.
. some lines won't have any other useful info that we can tag (e.g. log
lines from the postmaster or the stats collector).
Anything else related to the session that we want to include in the tag
could be done by an extremely easy extension to the recognized formats
(e.g. remote host addr, remote host name, remote port), without any
necessity to add another GUC var.
This patch has unfortunately suffered some bitrot, as I found yesterday
when I tried to apply it. This is hardly surprising given the amount of
time that has elapsed since it was prepared (which raises the question
of whether or not we should branch of the "release" branch earlier in
the process - i.e. around the time feature freeze is declared.).
I would *really* like to put this all to bed. The first feature above
seems quite uncontroversial, and is to my mind the more important in
that you can't get the info from log analysis tools. The second feature
has significant utility, has been requested by several users, and I
still think the way I did it back in August is the best way to go,
combining backwards compatibility with forwards flexibility and minimal
code disturbance, and preventing an explosion in GUC vars.
What is the best way to proceed so this can be wrapped up? Just fix the
bitrot and resubmit? Split it into 2? Other?
cheers
andrew