Re: Syslog and pg_options (for RPMs)
От | Tatsuo Ishii |
---|---|
Тема | Re: Syslog and pg_options (for RPMs) |
Дата | |
Msg-id | 20010209111257Z.t-ishii@sra.co.jp обсуждение исходный текст |
Ответ на | Re: Syslog and pg_options (for RPMs) (Lamar Owen <lamar.owen@wgcr.org>) |
Ответы |
Re: Syslog and pg_options (for RPMs)
|
Список | pgsql-hackers |
> > Precisely my point. I think working hard on syslog support inside elog > > is misplaced effort. > > Well, I can think of a few things: > 1.) Some messages are more important than others. Syslog levels are > useful to segreggate debug, errors, informational, and critical > messages. > 2.) Critical messages might need to go to more than one place, while > debug messages might need to be dropped silently unless further > configuration, etc, is performed. > 3.) Some messages need immediate attention -- syslog can go to the > console for level 'crit' messages. > > I know that those three points are part of the same point -- but stderr > is but a single stream, relegating all messages to the same priority. I > might want to keep critical messages far longer than debug messages. I > might want to keep FATAL, REALLYFATAL, and even ERROR messages longer > than logs of queries (a likely scenario). Good point. > Syslog support in elog(), with proper errorlevel coding, allows the > admin to segregate messages as he sees fit. Using logger(1) means all > messages are the same. Totally agreed. There are still many loggings using just plain fprintf(). They should be replaced by elog(DEBUG) or elog(NOTICE), IMHO. -- Tatsuo Ishii
В списке pgsql-hackers по дате отправления: