Re: log_line_info

From: "Andrew Dunstan" <andrew(at)dunslane(dot)net>
To: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: log_line_info
Date: 2004-03-03 11:23:44
Message-ID: 4500.24.211.141.25.1078313024.squirrel@www.dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Bruce Momjian said:
> Andrew Dunstan wrote:
>>
>> 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 ;-)
>
> Seems the cleanest would be to just print nothing for items that have
> no meaning for the postmaster.
>

Not quite clean enough - I also want to be able to supress irrelevant
literal characters. See the actual patch sent in on Feb 29th at
http://archives.postgresql.org/pgsql-patches/2004-02/msg00266.php where I
used the first variant I suggested above.

cheers

andrew

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Zeugswetter Andreas SB SD 2004-03-03 11:32:43 Re: [HACKERS] Tablespaces
Previous Message Claudio Natoli 2004-03-03 10:12:35 Re: [HACKERS] Tablespaces

Browse pgsql-patches by date

  From Date Subject
Next Message evanm 2004-03-03 12:46:31 initdb could use some lower default settings (trivial patch)
Previous Message Fabien COELHO 2004-03-03 10:04:29 Notice about costly ri checks