Thread: 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@%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).
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
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
Andrew Dunstan wrote: > >> 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. Yes, I understand there is no way to know if the literal characters are supposed to print for postmaster message, but is seems easier to just print them than to do the more complicated options you propose. One idea would be to suppress whitespace or perhaps special characters _after_ an option that is skipped --- not perfect, but this is only log output. Of course, if you do <%option>, you get the leading < but not the >. Maybe just go with suppressing trailing whitespace of a skipped option is best. Also, I think you should switch to lowercase like Peter suggested. You aren't supporting any of the printf() letters, so you might as well use lowercase. -- 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