Sanja, please fix that in 5.5, if applicable.

As I can see fix_query_cache_limit (as well other fix* functions) is not called on initialization with default value so I do not see how the patch can help except hiding the problem... maybe I am wrong, still checking...

Actually if fix_query_cache_limit function will be called during initialization then it will cause the same problem again and patch won't fix anything. If fix_query_cache_limit functions is not called on initialization then the patch reaches its goal – query_cache and Sys_query_cach_limit are initialized independently from each other and don't touch each other's data during initialization.

BTW, I noticed that query_cache initializes query_cache_limit to ULONG_MAX while Sys_query_cache_limit has maximum of UINT_MAX, so it may be worth checking what these values should be.

I think setting result size limit could be moved to QC initialization, and this (with above patch) will solve the problem.

Strictly speaking, there is no bug here. All command-line options (and query_cache_limit is a command-line option) are initialized run-time from handle_options() function of my_getopt.c. So whatever static initialization does and in what order is irrelevant.

But okay, one can argue that it's a fragile assumption to rely on (if we'd decide to remove a possibility of setting query_cache_limit from the command line, it will make its initial value non-deterministic). Let's fix it.

Oleksandr Byelkin — ok to push.

pushed to 10.0