On Mon, 2007-02-26 at 14:52 -0500, Tom Lane wrote:
> "Simon Riggs" <simon@2ndquadrant.com> writes:
> > On Mon, 2007-02-26 at 14:28 -0500, Tom Lane wrote:
> >> "Simon Riggs" <simon@2ndquadrant.com> writes:
> >>> The idea of the patch is that it generates a log message which then
> >>> invokes log_min_error_statement so that the SQL statement is displayed.
> >>> LOG is not on the list of options there, otherwise I would use it.
> >>
> >> As I said, you don't understand how the logging priority control works.
> >> LOG *is* the appropriate level for stuff intended to go to the server log.
>
> > Please look at the definition of log_min_error_statement, so you
> > understand where I'm coming from.
>
> I *have* read the definition of log_min_error_statement. (The SGML docs
> are wrong btw, as a quick look at the code shows that LOG is an accepted
> value.)
OK, I should have looked passed the manual.
> The real issue here is that send_message_to_server_log just does
>
> if (edata->elevel >= log_min_error_statement && debug_query_string != NULL)
>
> to determine whether to log the statement, whereas arguably it should be
> using a test like is_log_level_output --- that is, the priority ordering
> for log_min_error_statement should be like log_min_messages not like
> client_min_messages. We've discussed that before in another thread, but
> it looks like nothing's been done yet.
Hopefully not with me? Don't remember that.
> In any case, if you're unhappy
> with the code's choice of whether to emit the STATEMENT part of a log
> message, some changes here are what's indicated, not bizarre choices of
> elevel for individual messages.
Well, I would have chosen LOG if I thought it was available.
I'll do some more to the patch.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
