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
---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
