Re: log_line_info
От | Andrew Dunstan |
---|---|
Тема | Re: log_line_info |
Дата | |
Msg-id | 4500.24.211.141.25.1078313024.squirrel@www.dunslane.net обсуждение исходный текст |
Ответ на | Re: log_line_info (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: log_line_info
|
Список | pgsql-hackers |
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@%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@%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
В списке pgsql-hackers по дате отправления: