Bruce Momjian <pgman@candle.pha.pa.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.
> 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.
A fuller description of what I'm thinking of:
* log_min_messages should indeed be SUSET, and also the other log_xxx
switches.
* Output controlled by a log_xxx switch should have error level LOG.
* Output controlled by a debug_xxx switch should have error level DEBUG.
These switches remain USERSET.
* 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.
* 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.
If this seems reasonable, I can adjust the elevels while I'm making the
real-soon-now editing pass through the elog calls.
regards, tom lane
