The function that checks whether we can use keys for aggregates,
find_key_for_maxmin(), assumes that keys disabled by ALTER TABLE
... DISABLE KEYS are not in the set table->keys_in_use_for_query.
I.E., if a key is in this set, the optimizer assumes it is free to
use it.
The bug is that keys disabled with ALTER TABLE ... DISABLE KEYS still
appear in table->keys_in_use_for_query When the TABLE object has been
initialized with setup_tables(). Before setup_tables is called, however,
keys that are disabled in the aforementioned way are not included in
TABLE::keys_in_use_for_query.
The provided patch changes the code that updates keys_is_use_for_query so
that it assumes that keys_is_use_for_query already takes into account all
disabled keys, and generally all keys that should be used by the query.
it can't be compile everywhere if we just cast pointer to pthread_t
So now we use correct pthread_self() value as the pthread_t and
pointer where we need to identify the thread exactly.
binlog_filter and rpl_filter are initialized in server's 'main' function
which doesn't work in the embedded server. So this code moved to
function working in both cases.
Removed a lot of compiler warnings
Removed not used variables, functions and labels
Initialize some variables that could be used unitialized (fatal bugs)
%ll -> %l
Objects of the classes Item_func_is_not_null_test and Item_func_trig_cond
must be transparent for the method Item::split_sum_func2 as these classes
are pure helpers. It means that the method Item::split_sum_func2 should
look at those objects as at pure wrappers.
1) Two small windows cleanups for Archive.
2) Patch from Calvin for Falcon to be able to have its own I_S loaded. One example added for this, does hello world.
The bug report has demonstrated the following two problems.
1. If an ORDER/GROUP BY list includes a constant expression being
optimized away and, at the same time, containing single-row
subselects that return more that one row, no error is reported.
Strictly speaking the standard allows to ignore error in this case.
Yet, now a corresponding fatal error is reported in this case.
2. If a query requires sorting by expressions containing single-row
subselects that, however, return more than one row, then the execution
of the query may cause a server crash.
To fix this some code has been added that blocks execution of a subselect
item in case of a fatal error in the method Item_subselect::exec.
additional files that specify some actions which are allowed to the MySQL binaries.
Create a new subdirectory "supportfiles/RHEL4-SElinux" for them, and process it.
This fixes bug#12676.
