Re: fix log_min_duration_statement logic error

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > The reason we
> > needed to do it this way was so we could print the statement _after_ it
> > completes so we could include the duration.
>
> The behavior I had in mind was to dump the statement at the end of the
> query if (a) the duration needs to be printed and (b) the statement
> wasn't already dumped at the start --- ie, log_statement was not on
> at the start.
>
> The historical behavior of log_min_error_statement has been to make two
> separate log entries: the failing query and the error. This has worked
> well enough AFAIK; why not keep that behavior for log_min_duration?

I think separate entries work for log_min_error_statement because the
error string and query are both long, and you can pretty much guess
which error goes with which query, and you are looking at errors, which
are pretty rare events, hopefully.

I think they fit pretty nicely on one line, and lot of folks want that
information. I realize it looks like bloatware because it duplicates
some existing functionality, but I think it is a combination of duration
and statement output that can't be done easily separately.

Also, I don't see us combining any other log_* operations:

#log_connections = false
#log_duration = false
#log_pid = false
#log_statement = false
#log_timestamp = false
#log_hostname = false
#log_source_port = false

> BTW, there's a separate set of problems that have yet to be addressed,
> which is how any of these logging options apply for V3-protocol query
> operations. The existing code only seems to work for the old-style
> query path.

You mean how are they passed to the client? I assumed that would work
for pre-V3 clients.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073