ourdelta-developers team mailing list archive

[Wultsch <wultsch@xxxxxxxxx>]

On Tue, Nov 11, 2008 at 10:26 PM, Arjen Lentz <arjen@xxxxxxxxxxxxxxxx> wrote:
> Public bug reported:
>
> When long_query_time is really small, the slow log will also see queries
> that are not actually executed, for instance because of a syntax error.
> Naturally this is not desirable behaviour.
>
> The probable cause is actually likely to be with the original slow query
> log code and not with the microslow patch as such; with second-
> granularity, no syntax error query would ever take longer than a second
> to get through the parsing stage....
>
> ** Affects: ourdelta
>     Importance: Undecided
>         Status: New
>
> --
> microslow logs slow queries even if not executed
> https://bugs.launchpad.net/bugs/297060
> You received this bug notification because you are a member of OurDelta-
> developers, which is the registrant for OurDelta.
>
> Status in OurDelta - Builds for MySQL: New
>
> Bug description:
> When long_query_time is really small, the slow log will also see queries that are not actually executed, for instance because of a syntax error. Naturally this is not desirable behaviour.
>
> The probable cause is actually likely to be with the original slow query log code and not with the microslow patch as such; with second-granularity, no syntax error query would ever take longer than a second to get through the parsing stage....
>

I think this is not a bug. If a DBA decides that any query over that
takes over some period of time should be logged, and a query (with a
syntax error, or not) takes longer than that period it __should__ be
logged.

As long as the behavior is documented I do not see it as problematic.

-- 
Rob Wultsch

-- 
microslow logs slow queries even if not executed
https://bugs.launchpad.net/bugs/297060
You received this bug notification because you are a member of OurDelta-
developers, which is the registrant for OurDelta.

Status in OurDelta - Builds for MySQL: New

Bug description:
When long_query_time is really small, the slow log will also see queries that are not actually executed, for instance because of a syntax error. Naturally this is not desirable behaviour.

The probable cause is actually likely to be with the original slow query log code and not with the microslow patch as such; with second-granularity, no syntax error query would ever take longer than a second to get through the parsing stage....