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).
