Re: fix log_min_duration_statement logic error - Mailing list pgsql-patches

From Tom Lane
Subject Re: fix log_min_duration_statement logic error
Date
Msg-id 27711.1065326884@sss.pgh.pa.us
Whole thread Raw
In response to Re: fix log_min_duration_statement logic error  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: fix log_min_duration_statement logic error  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: fix log_min_duration_statement logic error  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-patches
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> 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.

Sure it can.  You're essentially arguing that DBAs are too dumb to match
up matching query and duration log outputs.  I don't buy that.  I think
they'll be analyzing their logs with little Perl scripts anyway, and
that consistency of log output format will be worth more to those
scripts than sometimes having related items all on one log line.

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

No, I mean the functionality isn't in the extended-query code path at
all, and it's not immediately clear where to insert it (eg, which steps
of parse/bind/execute do what logging, or where you measure duration).

            regards, tom lane

pgsql-patches by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: fix log_min_duration_statement logic error
Next
From: Bruce Momjian
Date:
Subject: Re: fix log_min_duration_statement logic error