Tom Lane <t...@sss.pgh.pa.us> wrote: > "Kevin Grittner" <kevin.gritt...@wicourts.gov> writes: >> The fact that LOG is categorized the same as INFO has led me to >> believe that they are morally equivalent -- > > They are not morally equivalent. INFO is for output that the user > has explicitly requested appear on his console (eg, via VACUUM > VERBOSE). So it's high priority for client output, not so much > for log output. LOG is for information that is considered high > priority to log, but not so much for client output (indeed maybe > there is no client to output it to). I didn't say I thought they meant the same thing. You omitted the part where I said >> -- that the only reason >> both exist is that one has entries of interest to system >> administrators and the other has interest to clients. Which I think is saying the same thing you just said. > If "LOG is over-used" then the problem is that we have LOG > messages that ought to be downgraded to DEBUG. A normally > functioning system should not be emitting *any* LOG messages > during routine business, other than ones that the user explicitly > requested (like log_connections). Current LOG level entries may be something which DBAs find as useful as you find the xmin/xmax breadcrumbs in tuples -- we normally don't want to look at all of these LOG entries, but we want them there to review in case of questions or problems. If anything of a time-critical nature is being written at the LOG level, I view that as a serious issue. We *should* have some logging level available to server processes which maps to something more serious than INFO in syslog and INFORMATION in the Windows event log but which doesn't indicate that something is being terminated. Perhaps we are currently using FATAL for these and I'm misunderstanding the issue. Even so, there seems to be a lot of room between LOG and FATAL, conceptually -- at least in the connotations those words have for me. ALERT keeps coming to mind. Maybe best mapped to NOTICE for syslog and WARNING for Windows event log. That seems to fill a gap in the logging levels. -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
