> > > Also, this disagrees with the run-time config docs which say that
> > > log_level can be from 0 to 4. The difference should be explained.
> >
> > I'm quite sure I did revise that; perhaps it needs a few more words.
> >
> > There are 8 levels; ERROR/WARN/CONFIG/INFO are ones that cannot be shut
> > off.  Your choices of log levels are 0 thru 4; at 0, only the
> > ERROR/WARN/CONFIG/INFO messages are shown.  At 1, DEBUG1 is added in.  At
> > 2, DEBUG2 is added as well.  DEBUG4 will show all possible levels.
>
> So we have -d and log_level both take a numeric argument that
> specifies how verbose the logging should be, but the numbers mean
> different log levels depending on which way they're passed in.

Better still, the command line behaviour appears to have been modified
to match the new config file behaviour, or at least the slon barfed
with

[0] WARN   5 is outside the valid range for parameter "log_level" (0 .. 4)

> > > 2) Debug level suggest a log level of 2 (WARN) and says this is "a
> > > routine, and, seemingly preferable choice". This is not what
> > > experience has demonstrated. As I recall we ran all logging at debug1
> > > since higher levels proved insufficient for troubleshooting. It seems
> > > reasonable to recommend debug1 for production systems where
> > > troubleshooting capabilities are required.
> >
> > No, you're mis-recalling this.  DEBUG2 is the level we have always been
> > using.  Levels 3 and 4 show too much stuff; there's something at level 3
> > that spits out a line for each tuple that is replicated.
>
> So... everyone agrees that DEBUG2 is the level that should be
> suggested for logging? And if that's the case, then perhaps the
> documentation should also be updated?

This is even better. If you follow the suggestion in the docs of using
log level "WARN", you count down the list of log levels and decide
that it's level 2. But that's actually DEBUG2, which appears to be a
pretty good choice for the actual log level of a production system.
Cool.

Andrew