
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

 




Mon, 19 Jan 2004 11:18:09 -0500
Andrew Dunstan <andrew@dunslane.net>
logging enhancement recap