Re: [HACKERS] Deadlock with pg_dump? - Mailing list pgsql-patches

From Tom Lane
Subject Re: [HACKERS] Deadlock with pg_dump?
Date
Msg-id 5346.1172519523@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Deadlock with pg_dump?  ("Simon Riggs" <simon@2ndquadrant.com>)
Responses Re: [HACKERS] Deadlock with pg_dump?
List pgsql-patches
"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.)

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.  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.

            regards, tom lane

pgsql-patches by date:

Previous
From: "Simon Riggs"
Date:
Subject: Re: [HACKERS] Deadlock with pg_dump?
Next
From: "Simon Riggs"
Date:
Subject: Re: [HACKERS] Deadlock with pg_dump?