Re: Statements with syntax errors are not logged - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Statements with syntax errors are not logged
Date
Msg-id 13986.1161271997@sss.pgh.pa.us
Whole thread Raw
In response to Re: Statements with syntax errors are not logged  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: Statements with syntax errors are not logged  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane wrote:
>> To some extent the logging 
>> settings are only meant to capture successfully executed statements

> Then it should be changed to log *only* successfully executed statements 
> and explicitly documented as such.

Well, maybe we should do that.  It'd be relatively easy to handle the
ALL case before parsing and the other cases after in the "simple query"
code path, but I don't see any nice way to make it work in the
parse/bind/execute code path.  As the code stands in HEAD, we don't
normally log parse/bind messages at all, just execute messages, because
there's no way to avoid serious redundancy/log-bloat/confusion otherwise.
Another attractive aspect is that we could merge duration logging with
statement reporting rather than having two separate log messages come
out in some cases.

The other thing we'd want to do is try a bit harder to ensure that
debug_query_string is always valid, so that one could be certain that
the combination of log_min_error_statement and log_statement = ALL
tells all.  bind/execute messages don't currently bother to set
debug_query_string properly, but I think that could be fixed easily.

Comments?
        regards, tom lane


pgsql-hackers by date:

Previous
From: tomas@tuxteam.de
Date:
Subject: Re: Statements with syntax errors are not logged
Next
From: Tom Lane
Date:
Subject: Re: Additional stats for Relations