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(at)%D(%C:%S %I line:%L "
- have a special marker where what follows is the postmaster variant,
defaulting to the beginning if not found.
Examples: "%T [%P]: " (everybody gets timestamp and pid)
"%T [%P]: %U(at)%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(at)%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).