Re: log_line_info
| От | Bruce Momjian |
|---|---|
| Тема | Re: log_line_info |
| Дата | |
| Msg-id | 200403030503.i2353MY02650@candle.pha.pa.us обсуждение исходный текст |
| Ответ на | log_line_info (Andrew Dunstan <andrew@dunslane.net>) |
| Ответы |
Re: log_line_info
|
| Список | pgsql-hackers |
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. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
В списке pgsql-hackers по дате отправления: