Thread: elog(LOG), elog(DEBUG)
There's a TODO item to make elog(LOG) a separate level. I propose the name INFO. It would be identical to DEBUG in effect, only with a different label. Additionally, all DEBUG logging should either be disabled unless the debug_level is greater than zero, or alternatively some elog(DEBUG) calls should be converted to INFO conditional on a configuration setting (like log_pid, for example). The stricter distinction between DEBUG and INFO would also yield the possibility of optionally sending DEBUG output to the frontend, as has been requested a few times. -- Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
* Peter Eisentraut <peter_e@gmx.net> [010505 02:06] wrote: > There's a TODO item to make elog(LOG) a separate level. I propose the > name INFO. It would be identical to DEBUG in effect, only with a > different label. Additionally, all DEBUG logging should either be > disabled unless the debug_level is greater than zero, or alternatively > some elog(DEBUG) calls should be converted to INFO conditional on a > configuration setting (like log_pid, for example). > > The stricter distinction between DEBUG and INFO would also yield the > possibility of optionally sending DEBUG output to the frontend, as has > been requested a few times. INFO makes sense as afaik it maps to syslog. -- -Alfred Perlstein - [alfred@freebsd.org] Daemon News Magazine in your snail-mail! http://magazine.daemonnews.org/
Peter Eisentraut <peter_e@gmx.net> writes:
> There's a TODO item to make elog(LOG) a separate level. I propose the
> name INFO. It would be identical to DEBUG in effect, only with a
> different label.
This conveys nothing to my mind. How should I determine whether a given
elog call ought to use INFO or DEBUG?
> The stricter distinction between DEBUG and INFO would also yield the
> possibility of optionally sending DEBUG output to the frontend, as has
> been requested a few times.
It's not a "strict distinction" unless we have a clear policy as to what
the different levels mean. I think setting and documenting that policy
is the hard part of the task.
regards, tom lane
Tom Lane writes: > Peter Eisentraut <peter_e@gmx.net> writes: > > There's a TODO item to make elog(LOG) a separate level. I propose the > > name INFO. It would be identical to DEBUG in effect, only with a > > different label. > > This conveys nothing to my mind. How should I determine whether a given > elog call ought to use INFO or DEBUG? DEBUG is for messages intended to help locating and analyzing faults in the source code (i.e., debugging). Normal users don't need this during normal operation. INFO (or whatever the name) is for messages that administrator's might be interested in for auditing and tuning. Example: elog(DEBUG, "heapgettup(..., b=0x%x, nkeys=%d, key=0x%x", buffer, nkeys, key); vs. elog(INFO, "connection: host=%s user=%s database=%s", ...); There are maybe a dozen potential INFO messages, plus a few to be converted fprintf's. -- Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
> Tom Lane writes: > > > Peter Eisentraut <peter_e@gmx.net> writes: > > > There's a TODO item to make elog(LOG) a separate level. I propose the > > > name INFO. It would be identical to DEBUG in effect, only with a > > > different label. > > > > This conveys nothing to my mind. How should I determine whether a given > > elog call ought to use INFO or DEBUG? > > DEBUG is for messages intended to help locating and analyzing faults in > the source code (i.e., debugging). Normal users don't need this during > normal operation. > > INFO (or whatever the name) is for messages that administrator's might be > interested in for auditing and tuning. Seems like a good idea. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026