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