log_line_info

I haven't had any other feedback on this patch that I posted. However, 
I'm a bit dissatisfied with it for a couple of reasons:

. when a connection is logged we don't yet know the user and database, 
because we haven't processed the initial packet yet. That causes %U and 
%D to produce empty strings, which looks mildly ugly. I'm inclined in 
this case to emit something like "****" or "[unknown]" for these escapes.

. we don't produce any output for postmaster, stats collector etc. 
processes. If we really want to get rid of log_pid and log_timestamp 
this needs to be dealt with, IMNSHO. We could handle that in a few ways: - have a separate GUC var
(log_line_info_postmaster?)Not much gain 
 
over keeping the existing vars, though - have a special marker in the string (%X maybe) that says stop 
processing for postmaster here.   Example: "%T [%P]:%X %U@%D(%C:%S %I line:%L " - have a special marker where what
followsis the postmaster variant, 
 
defaulting to the beginning if not found.   Examples: "%T [%P]: " (everybody gets timestamp and pid)             "%T
[%P]:%U@%D(%C:%S %I line:%L %X%T [%P]:" (same effect 
 
as example under previous point) - something else I haven't thought of ;-)

Comments welcome

cheers

andrew


Andrew Dunstan wrote:

>
> Attached is a patch for tagging log lines produced by backends. It is 
> not quite ready for application - this is for people to look over and 
> play with.
>
> For my testing I used the following settings:
>
> log_connections = true
> log_disconnections = true
> log_line_info = '%T [%P] %U@%D(%C:%S) %I line:%L '
> log_statement = true
> log_hostname = true
> log_source_port = true
>
>
> Comments welcome
>
> (Rod Taylor has suggested adding in escapes for remote host and remote 
> port. This can be done easily enough - I want to call a halt at some 
> stage and get the basics of this in. Extending it will then be easy).