Re: [BUGS] Bug #928: server_min_messages (log_min_messages

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > Tom Lane wrote:
> >> IIRC, all that stuff goes through elog (if there's anything left in the
> >> standard build that writes straight to stderr, we need to be fixing the
> >> code, not messing with GUC defaults). So AFAIK the log_min_messages
> >> setting ought to control it all. What are you seeing that I don't?
>
> > I tried this as a non-super user and saw the parser info in the logs.
>
> Yeah, but if log_min_messages becomes SUSET, then a non-superuser can't
> force debug info into the log. At least not if we change its elevel to
> DEBUG rather than LOG, which I think would be a reasonable compromise.
> The real problem here is the choice of LOG as the elevel for output
> controlled by the debug_xxx switches.

Yes. I set debug_* output to LOG at the time I did the error leveling
because it traditionally has gone to the server logs. Now that we can
send to the client, it makes sense to move it to DEBUG1. The downside
is that setting the debug_ variables will send output _nowhere_ until
you change client_min_messages or log_min_messages. It clearly makes
the debug_* variables treat the client and serve logs the same way in
terms of output preference, and I think this makes sense. We just need
to be prepared to communicate that change in the release notes.

> > I suppose you could set log_min_messages above LOG, but that seems too
> > dangerous. I don't have a problem changing only the log_* settings, but
> > we shouldn't assume there is any way to protect the log file. I think
> > we are restricting the log_* settings only so they can not be supressed
> > ffrom the logs.
>
> The thing is that I thought it was a major step forward for users to be
> able to get debug info at their consoles, rather than needing access to
> the system log to see it. If we make these settings SUSET then we're
> taking that away again, and that's really not good.

Right.

> A fuller description of what I'm thinking of:
>
> * log_min_messages should indeed be SUSET, and also the other log_xxx
> switches.

OK, will apply.

> * Output controlled by a log_xxx switch should have error level LOG.

I thought it already did. If not, it certainly should.

> * Output controlled by a debug_xxx switch should have error level DEBUG.
> These switches remain USERSET.

OK. One issue is that I think you should make them all DEBUG1, and move
any existing DEBUG1 references to DEBUG2, perhaps moving DEBUG2 up as
well. Here are the totals for the various DEBUG* uses:

$ gid DEBUG1|wc -l
82
$ gid DEBUG2|wc -l
27
$ gid DEBUG3|wc -l
63
$ gid DEBUG4|wc -l
4
$ gid DEBUG5|wc -l
5

Seems we should push them all up, and merge DEBUG 4 and 5, and use
DEBUG1 for the debug_* output. That seems logical.

> * Adjust all other debug output (non-switch-controlled) to have error
> level DEBUG2 or below; this way, setting log_min_messages = DEBUG gets
> you only the specifically requested output.

Oh, I see you already had that idea! :-)

> * Note in the Admin Guide that log_min_messages <= DEBUG is needed
> if you want any debug_xxx output to appear in the log, and that this
> setting can produce very voluminuous output.

Good idea. This allows us to easily get debug_* stuff to the client
_without_ getting it in the server.

> If this seems reasonable, I can adjust the elevels while I'm making the
> real-soon-now editing pass through the elog calls.

I can do the change easily here. It will take just a few minutes. Let
me know and I can complete it in an hour.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073