Re: bzr commit into mysql-5.1-bugteam branch (Dao-Gang.Qu:3192) Bug#42851

[He Zhenxing]

Andrei Elkin wrote:
> After sleeping, and sleeping on this matter I think we would agree on
> 
> 1. Rating for the error log  should be done per session

Bug#42851 is about limiting **warnings** written into error log, error
messages will not be affected by this. So I think it's not necessary
that we need to make sure that every session got a chance to output it's
warnings. I think a global limitation over all warnings generated by the
server is good enough.

> 2. Rating should target at duplicate messages

Remove duplicated messages can reduce messages written into the error
log, but this can not solve the problem of bug#42851, we still need a
way to limit the total numbers of warnings going into error log within a
interval.

And I think the mechanism to remove duplicated messages should be done
for all kinds of messages written into error log, not just warnings.

> 
> Per implementation, I still think the numeric id, not a checksum is the key that
> should be associated 
> with the number of hits. That is because many of the messages have variable body.
> Expiration logics can be borrowed from the submitted patch.
> 
> Technically  rate_limit_impl() could be extended with maintaining a private to
> THD of the session the-mess-id-number-of-hits hash.
> 
> cheers,
> 
> Andrei
> 
> 
> 
> 
>    Dao Gang, Davi, Serge, hello.
> 
>       >
>       > The patch introduces the global limit whereas a limit per session might be
> a better
>       > solution.
>       > The global limitting has a drawback that if for instance two connectons
> try logging
>       > the limit value can be hit by the first-and-only error message of the 2nd
> session.
>       > Therefore the error-log observer would miss that 2nd session error
> message.
>       >
>       > Was that really disscussed before?   
> 
>       Yes. We have discussed it. The 'a limit per session' solution will make the
>       volume of messages become uncontrollable, because the number of session is
>       inconstant.
> 
>    But it's still limitted (let's call that C_max). Hence, if your two parameters
> applied in the session scope
> 
>    --session-log-warnings-ratelimit-interval = 10
>    --session-log-warnings-ratelimit-burst = 5
> 
>    thier accumulative effect would be roughly the same as
> 
>    --server-log-warnings-ratelimit-interval = 10
>    --server-log-warnings-ratelimit-burst = 5 * C_max
> 
>    but with the obvious advantage in that all sessions will contribute to the log.
>    Another advantage is in that the sessions can be discriminated on the basis of the
> parameters.
> 
>    The above approach does not cover a concern that all messages needs presenting in
> the log, at least one time.
>    If we set up our goal that way then discussion that Sergei and Davi held on #dev
> today
>    could guide us to the solution.
>    Let me note here, that checksumming of the message can be replaced by
>    the warning numeric id which is cheap computatioan-wise but would force
>    us to enumerate all warnings that exist without ids.