Simon Riggs wrote:
> On Mon, 2007-02-26 at 13:34 -0500, Bruce Momjian wrote:
>
> > I am a little concerned about a log_* setting that is INFO. I understand
> > why you used INFO (for log_min_error_messages), but INFO is inconsistent
> > with the log* prefix, and by default INFO doesn't appear in the log
> > file.
>
> Yeh, LOG would be most appropriate, but thats not possible.
>
> log_min_messages allows only DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1,
> INFO, NOTICE and WARNING for non-error states.
>
> Possibly DEBUG1?
This highlights a problem we have often had with LOG output where we
also want the query.
I think there are two possible approaches. First, we could add a new
bitmap value like LOG_STATEMENT to ereport when we want the statement
with the log line:
ereport (LOG | LOG_STATEMENT, ...)
(or a new LOG_WITH_STATEMENT log level) and a new GUC like
"log_include_statement" that would control the output of statements for
certain GUC parameters, and we document with GUC values it controls.
A simpler idea would be to unconditionally include the query in the
errdetail() of the actual LOG ereport.
This is not the first GUC that has needed this. We had this issue with
"log_temp_files", which we just added, and the only suggested solution
was to use log_statement = 'all'. Either of these ideas above would be
useful for this as well.
--
Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
