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 947.1065370241@sss.pgh.pa.us
Whole thread Raw
In response to Re: fix log_min_duration_statement logic error  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: fix log_min_duration_statement logic error  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-patches
Peter Eisentraut <peter_e@gmx.net> writes:
> When you're dealing with a large installation, these little Perl scripts
> become difficult.  I've just had to deal with a similar issue with a
> popular MTA which spreads the relevant log information over several lines.
> If you're generating 500 MB of log output a day, it becomes a problem.

True, but it would take really serious revisions of our log output
formatting to fix things so that a naive "grep" will be useful for much
of anything.

To take just the most obvious limitation in what Bruce is proposing: a
grep for "duration" will yield the duration and the first line of the
SQL command.  If an installation is in the habit of breaking their SQL
into multiple lines, this will be less than useful.  Some people like
to format their code like this:

    SELECT
        a, b, c
    FROM
        ...

in which case showing just the first line will be quite content-free.

There are already similar problems with extracting error information
from the logs (and the 7.4 redesign of error formatting has made 'em
worse).

If we are going to try to design the log output so that you don't need
reassembly scripts to link related lines together, then we have got lots
bigger problems to fix than log_duration.  I'm not convinced it's an
appropriate goal at all, though.

            regards, tom lane

pgsql-patches by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: fix log_min_duration_statement logic error
Next
From: Tom Lane
Date:
Subject: Re: fix log_min_duration_statement logic error