The problem is that cond->fix_fields(thd, 0) breaks
condition(cuts off 'having'). The reason of that is
that NULL valued Item pointer is present in the
middle of Item list and it breaks the Item processing
loop.
mysql-test/r/having.result:
test case
mysql-test/t/having.test:
test case
sql/item_cmpfunc.h:
added ASSERT to make sure that we do not add NULL valued Item pointer
sql/sql_select.cc:
skip adding an item to condition if Item pointer is NULL.
skip adding a list to condition if this list is empty.
performance degradation.
Filesort + join cache combination is preferred to full index scan because it
is usually faster. But it's not the case when the index is clustered one.
Now test_if_skip_sort_order function prefers filesort only if index isn't
clustered.
mysql-test/r/innodb_mysql.result:
Added a test case for the bug#50843.
mysql-test/t/innodb_mysql.test:
Added a test case for the bug#50843.
sql/sql_select.cc:
Bug#50843: Filesort used instead of clustered index led to
performance degradation.
Now test_if_skip_sort_order function prefers filesort only if index isn't
clustered.
The problem was in an incorrect debug assertion. The expression
used in the failing assertion states that when finding
references matching ORDER BY expressions, there can be only one
reference to a single table. But that does not make any sense,
all test cases for this bug are valid examples with multiple
identical WHERE expressions referencing the same table which
are also present in the ORDER BY list.
Fixed by removing the failing assertion. We also have to take
care of the 'found' counter so that we count multiple
references only once. We rely on this fact later in
eq_ref_table().
mysql-test/r/join.result:
Added a test case for bug #50335.
mysql-test/t/join.test:
Added a test case for bug #50335.
sql/sql_select.cc:
Removing the assertion in eq_ref_table() as it does not make
any sense. We also have to take care of the 'found' counter so
that we count multiple references only once. We rely on this
fact later in eq_ref_table().
The problem is that during temporary table creation uneven bits
are not taken into account for hidden fields. It leads to incorrect
calculation&allocation of null bytes size for table record. And
if grouped value is null we set wrong bit for this value(see end_update()).
Fixed by adding separate calculation of uneven bit for hidden fields.
mysql-test/r/type_bit.result:
test case
mysql-test/t/type_bit.test:
test case
sql/sql_select.cc:
added separate calculation of uneven bit for hidden fields
column is used for ORDER BY
Problem: filesort isn't meant for null length sort data
(e.g. char(0)), that leads to a server crash.
Fix: disregard sort order if sort data record length is 0 (nothing
to sort).
mysql-test/r/select.result:
Fix for bug#49897: crash in ptr_compare when char(0) NOT NULL
column is used for ORDER BY
- test result.
mysql-test/t/select.test:
Fix for bug#49897: crash in ptr_compare when char(0) NOT NULL
column is used for ORDER BY
- test case.
sql/filesort.cc:
Fix for bug#49897: crash in ptr_compare when char(0) NOT NULL
column is used for ORDER BY
- assert added as filesort cannot handle null length sort data.
sql/sql_select.cc:
Fix for bug#49897: crash in ptr_compare when char(0) NOT NULL
column is used for ORDER BY
- don't sort null length data e.g. in case of ORDER BY CHAR(0).
The problem becomes apparent only if HAVE_purify is undefined.
It related to the part of code placed in open_table_from_share() fuction
where we initialize record buffer only if HAVE_purify is enabled.
So in case of HAVE_purify=OFF record buffer is not initialized
on open table stage.
Next we read key, find NULL value and update appropriate null bit
but do not update record buffer. After that the record is stored
in the join cache(store_record_in_cache). For CHAR fields we
strip trailing spaces and in our case this procedure uses
uninitialized record buffer.
The fix is to skip stripping space procedure in case of null values
for CHAR fields(partially based on 6.0 JOIN_CACHE implementation).
mysql-test/r/join.result:
test case
mysql-test/t/join.test:
test case
sql/field.cc:
code updated according to new CACHE_FIELD struct
sql/sql_select.cc:
code updated according to new CACHE_FIELD struct
sql/sql_select.h:
CACHE_FIELD struct:
added new fields: Field *field, uint type;
removed fields: Field_blob *blob_field, bool strip;
Queries optimized with GROUP_MIN_MAX didn't cleanup KEYREAD
optimization properly. As a result subsequent queries may
return incomplete rows (fields are initialized to default
values).
mysql-test/r/group_min_max.result:
A test case for BUG#49902.
mysql-test/t/group_min_max.test:
A test case for BUG#49902.
sql/opt_range.cc:
Refactor of KEYREAD optimization switch so that KEYREAD
handler state is in sync with st_table::key_read flag.
All SQL code is supposed to switch KEYREAD optimization
via st_table::set_keyread().
sql/opt_sum.cc:
Refactor of KEYREAD optimization switch so that KEYREAD
handler state is in sync with st_table::key_read flag.
All SQL code is supposed to switch KEYREAD optimization
via st_table::set_keyread().
sql/sql_select.cc:
Refactor of KEYREAD optimization switch so that KEYREAD
handler state is in sync with st_table::key_read flag.
All SQL code is supposed to switch KEYREAD optimization
via st_table::set_keyread().
sql/sql_update.cc:
Refactor of KEYREAD optimization switch so that KEYREAD
handler state is in sync with st_table::key_read flag.
All SQL code is supposed to switch KEYREAD optimization
via st_table::set_keyread().
sql/table.cc:
Refactor of KEYREAD optimization switch so that KEYREAD
handler state is in sync with st_table::key_read flag.
All SQL code is supposed to switch KEYREAD optimization
via st_table::set_keyread().
sql/table.h:
Refactor of KEYREAD optimization switch so that KEYREAD
handler state is in sync with st_table::key_read flag.
All SQL code is supposed to switch KEYREAD optimization
via st_table::set_keyread().
Grouping by a subquery in a query with a distinct aggregate
function lead to a wrong result (wrong and unordered
grouping values).
There are two related problems:
1) The query like this:
SELECT (SELECT t1.a) aa, COUNT(DISTINCT b) c
FROM t1 GROUP BY aa
returned wrong result, because the outer reference "t1.a"
in the subquery was substituted with the Item_ref item.
The Item_ref item obtains data from the result_field object
that refreshes once after the end of each group. This data
is not applicable to filesort since filesort() doesn't care
about groups (and doesn't update result_field objects with
copy_fields() and so on). Also that data is not applicable
to group separation algorithm: end_send_group() checks every
record with test_if_group_changed() that evaluates Item_ref
items, but it refreshes those Item_ref-s only after the end
of group, that is a vicious circle and the grouped column
values in the output are shifted.
Fix: if
a) we grouping by a subquery and
b) that subquery has outer references to FROM list
of the grouping query,
then we substitute these outer references with
Item_direct_ref like references under aggregate
functions: Item_direct_ref obtains data directly
from the current record.
2) The query with a non-trivial grouping expression like:
SELECT (SELECT t1.a) aa, COUNT(DISTINCT b) c
FROM t1 GROUP BY aa+0
also returned wrong result, since JOIN::exec() substitutes
references to top-level aliases in SELECT list with Item_copy
caching items. Item_copy items have same refreshing policy
as Item_ref items, so the whole groping expression with
Item_copy inside returns wrong result in filesort() and
end_send_group().
Fix: include aliased items into GROUP BY item tree instead
of Item_ref references to them.
mysql-test/r/group_by.result:
Test case for bug #45640
mysql-test/t/group_by.test:
Test case for bug #45640
sql/item.cc:
Bug #45640: optimizer bug produces wrong results
Item_field::fix_fields() has been modified to resolve
aliases in GROUP BY item trees into aliased items instead
of Item_ref items.
sql/item.h:
Bug #45640: optimizer bug produces wrong results
- Item::find_item_processor() has been introduced.
- Item_ref::walk() has been modified to apply processors
to itself too (not only to referenced item).
sql/mysql_priv.h:
Bug #45640: optimizer bug produces wrong results
fix_inner_refs() has been modified to accept group_list
parameter.
sql/sql_lex.cc:
Bug #45640: optimizer bug produces wrong results
Initialization of st_select_lex::group_fix_field has
been added.
sql/sql_lex.h:
Bug #45640: optimizer bug produces wrong results
The st_select_lex::group_fix_field field has been introduced
to control alias resolution in Itef_fied::fix_fields.
sql/sql_select.cc:
Bug #45640: optimizer bug produces wrong results
- The fix_inner_refs function has been modified to treat
subquery outer references like outer fields under aggregate
functions, if they are included in GROUP BY item tree.
- The find_order_in_list function has been modified to
fix Item_field alias fields included in the GROUP BY item
trees in a special manner.
Fixed 2 problems :
1. test_if_order_by_key() was continuing on the primary key
as if it has a primary key suffix (as the secondary keys do).
This leads to crashes in ORDER BY <pk>,<pk>.
Fixed by not treating the primary key as the secondary one
and not depending on it being clustered with a primary key.
2. The cost calculation was trying to read the records
per key when operating on ORDER BYs that order on all of the
secondary key + some of the primary key.
This leads to crashes because of out-of-bounds array access.
Fixed by assuming we'll find 1 record per key in such cases.
fulltext search and row op.
The search for fulltext indexes is searching for some special
predicate layouts. While doing so it's not checking for the number
of columns of the expressions it tries to calculate.
And since row expressions can't return a single scalar value there
was a crash.
Fixed by checking if the expressions are scalar (in addition to
being constant) before calling Item::val_xxx() methods.
- Marked a couple of tests with --big
- Fixed xtradb/handler/ha_innodb.cc to call explain_filename()
storage/xtradb/handler/ha_innodb.cc:
Call explain_filename() to get proper names for partitioned tables
subselect_single_select_engine::exec()
When a subquery doesn't need to be evaluated because
it returns only aggregate functions and these aggregates
can be calculated from the metadata about the table it
was not updating all the relevant members of the JOIN
structure to reflect that this is a constant query.
This caused problems to the enclosing subquery
('<> SOME' in the test case above) trying to read some
data about the tables.
Fixed by setting const_tables to the number of tables
when the SELECT is optimized away.
error in the query.
Fixes a leak after materializing a GROUP BY subquery to a
temp table when the subquery has a blob column in the SELECT
list.
Fixed by correctly destructing temporary buffers after doing
the conversion.
flush_cached_records() was not correctly checking for errors after calling
Item::val_xxx() methods. The expressions may contain subqueries
or stored procedures that cause errors that should stop the statement.
Fixed by correctly checking for errors and propagating them up the call stack.
Need to make sure the tmp join doesn't point to the structure already
freed by the cleanup() for the "base" join, as this can lead to
double free, because sometimes both tmp_join and join point to the
same tmp_table_params.copy_field array.
error in the query.
Fixes a leak after materializing a GROUP BY subquery to a
temp table when the subquery has a blob column in the SELECT
list.
Fixed by correctly destructing temporary buffers for re-usable
queries
Several problems fixed :
1. Non constant expressions in UNION ... ORDER BY were not correctly cleaned up
in st_select_lex_unit::cleanup() causing crashes in EXPLAIN EXTENDED because of
fields quoted by these expressions pointing to the already freed temporary table
used to calculate the UNION.
Fixed by correctly cleaning up expressions of any depth.
2. Subqueries in the order by part of UNION ... ORDER BY ... caused a crash in
EXPLAIN EXTENDED because of a transformation attempt made during EXPLAIN EXTENDED
execution. Fixed by not doing the transformation when in EXPLAIN.
3. Fulltext functions caused crash when in the ORDER BY part of an un-parenthesized
UNION that gets "promoted" to be valid for the whole union, e.g.
SELECT * FROM t1 UNION SELECT * FROM t2 ORDER BY MATCHES (a) AGAINST ('abc' IN BOOLEAN MODE).
This is a case that demonstrates a more general problem of parts of the query being
moved to another level. When doing such transformation late in the optimization run
when most of the flags about the contents of the query are already aggregated it's possible
to "split" the flags so that they correctly reflect the new queries after the transformation.
In specific the ST_SELECT_LEX::ftfunc_list is holding all the free text function for all the
parts of the second SELECT in the UNION and we don't know what part of that is in the ORDER BY
that we're to move to the UNION level and what part is about the other parts of the second SELECT.
Fixed by throwing and error when such statements are about to be processed by adding a check
for the presence of MATCH() inside the ORDER BY clause that's going to get promoted to UNION.
To workaround this new limitation one must parenthesize the UNION SELECTs and provide a real
global ORDER BY for the UNION outside of the parenthesis.
on re-execution of prepared statement
Problem: some (see eq_ref_table()) ORDER BY/GROUP BY optimization
is called before each PS execution. However, we don't properly
initialize its stucture every time before the call.
Fix: properly initialize the sturture used.
mysql-test/r/ps.result:
Fix for bug#49570: Assertion failed: !(order->used & map)
on re-execution of prepared statement
- test result.
mysql-test/t/ps.test:
Fix for bug#49570: Assertion failed: !(order->used & map)
on re-execution of prepared statement
- test case.
sql/sql_select.cc:
Fix for bug#49570: Assertion failed: !(order->used & map)
on re-execution of prepared statement
- set order->used to 0 before each eq_ref_table() call,
as the function relies on that.
returns incorrect results with where
An outer join of a const table (outer) and a normal table
(inner) with GROUP BY on a field from the outer table would
optimize away GROUP BY, and thus trigger the optimization to
do away with a temporary table if grouping was performed on
columns from the const table, hence executing the query with
filesort without temporary table. But this should not be
done if there is a non-indexed access to the inner table,
since filesort does not handle joins. It expects either ref
access, range ditto or table scan. The join condition will
thus not be applied.
Fixed by always forcing execution with temporary table in
the case of ROLLUP with a query involving an outer join. This
is a slightly broader class of queries than need fixing, but
it is hard to ascertain the position of a ROLLUP field wrt
outer join with current query representation.
mysql-test/r/join_outer.result:
Bug#47650: Test result
mysql-test/t/join_outer.test:
Bug#47650: Test case
sql/sql_select.cc:
Bug#47650: Fix
int join_read_key(JOIN_TAB*)
The eq_ref access method TABLE_REF (accessed through
JOIN_TAB) to save state and to track if this is the
first row it finds or not.
This state was not reset on subquery re-execution
causing an assert.
Fixed by resetting the state before the subquery
re-execution.
int join_read_key(JOIN_TAB*)
The eq_ref access method TABLE_REF (accessed through
JOIN_TAB) to save state and to track if this is the
first row it finds or not.
This state was not reset on subquery re-execution
causing an assert.
Fixed by resetting the state before the subquery
re-execution.
This fix has been proposed by Sergey Petrunya and has been contributed
under SCA by sca@askmonty.org.
The cause for this valgrind error is that in the function
add_cond_and_fix() in sql_select.cc an Item_cond_and object is
created. This is marked as fixed but does not have a correct
table_map() attribute. Later, in make_join_select(), if
engine_condition_pushdown is in use, this table map is used and
results in the valgrind error.
The fix is to add a call to update_used_tables() in add_cond_and_fix()
so that the table map is updated correctly.
This patch is tested by multiple existing tests (e.g. the tests
innodb_mysql, innodb, fulltext, compress all produces this valgrind
warning/error without this fix).
sql/sql_select.cc:
In add_cond_and_fix() add a call to update_used_tables() to ensure
the table map is updated.
Part 2 :
There was a special optimization on the ref access method for
ORDER BY ... DESC that was set without actually looking on the type of the
selected index for ORDER BY.
Fixed the SELECT ... ORDER BY .. DESC (it uses a different code path compared
to the ASC that has been fixed with the previous fix).
field='const1' AND field='const2' in some cases
Building multiple equality predicates containing
a constant which is compared as a datetime (with a field)
we should take this fact into account and compare the
constant with another possible constatns as datetimes
as well.
E.g. for the
SELECT ... WHERE a='2001-01-01' AND a='2001-01-01 00:00:00'
we should compare '2001-01-01' with '2001-01-01 00:00:00' as
datetimes but not as strings.
mysql-test/r/select.result:
Fix for bug#49199: Optimizer handles incorrectly:
field='const1' AND field='const2' in some cases
- test result.
mysql-test/t/select.test:
Fix for bug#49199: Optimizer handles incorrectly:
field='const1' AND field='const2' in some cases
- test case.
sql/item_cmpfunc.cc:
Fix for bug#49199: Optimizer handles incorrectly:
field='const1' AND field='const2' in some cases
- adding a constant to Item_equal compare it as
a datetime value with stored one if there's a
date[time] field in a equality predicate.
sql/item_cmpfunc.h:
Fix for bug#49199: Optimizer handles incorrectly:
field='const1' AND field='const2' in some cases
- adding a constant to Item_equal compare it as
a datetime value with stored one if there's a
date[time] field in a equality predicate.
sql/sql_select.cc:
Fix for bug#49199: Optimizer handles incorrectly:
field='const1' AND field='const2' in some cases
- adding a constant to Item_equal compare it as
a datetime value with stored one if there's a
date[time] field in a equality predicate.
- Removed some not needed casts
- Change plugin.h to be 'binary compatible' with old versions
- Added mysql_ft_size_t typedef to plugin.h to make it trivial to change string lengths to size_t on next ABI change
- Made some fixes suggested by Kristian to make things more portable and future safe (when it comes to strict aliasing)
include/ft_global.h:
Introduced FT_WEIGTH, to handle fulltext weights in a slightly more portable manner
include/mysql/plugin.h:
Change plugin.h to be 'binary compatible' with old versions
Added mysql_ft_size_t typedef to plugin.h to make it trivial to change string lengths to size_t on next ABI change
Changed flags to unsigned (as flags should always be unsigned)
mysql-test/t/information_schema.test:
Fixed typo
sql/sp_head.cc:
Removed cast
sql/sql_select.cc:
Removed cast
sql/table.cc:
Removed cast
storage/maria/ma_ft_boolean_search.c:
Use mysql_ft_size_t instead of size_t for plugin.h code
Changed some other string lengths to size_t
storage/maria/ma_ft_nlq_search.c:
Use FT_WEIGTH to make code more portable
storage/maria/ma_ft_parser.c:
Use mysql_ft_size_t instead of size_t for plugin.h code
Changed some other string lengths to size_t
storage/maria/ma_ftdefs.h:
Changed some string lengths to size_t
storage/maria/maria_ftdump.c:
Use FT_WEIGTH to make code more portable
storage/myisam/ft_boolean_search.c:
Use mysql_ft_size_t instead of size_t for plugin.h code
storage/myisam/ft_nlq_search.c:
Use FT_WEIGTH to make code more portable
storage/myisam/ft_parser.c:
Use mysql_ft_size_t instead of size_t for plugin.h code
storage/myisam/myisam_ftdump.c:
Use FT_WEIGTH to make code more portable
Don't use static link by default (in compile-pentium) as some new systems doesn't have all static libraries available
Change type for functions in plugin.h:str_mysql_ftparser_param() to const unsigned char and string lengths to size_t.
One effect of the above change is that one needs to include mysql_global.h or define size_t before including plugin.h
This fixes a case where mysql_client_test failed with newer gcc that enables strict-aliasing by default
BUILD/compile-pentium:
Don't use static link by default as some new systems doesn't have all static libraries available
client/mysql_upgrade.c:
Remove not used variable
cmd-line-utils/readline/config_readline.h:
Define some constants to get rid of compiler warnings on Linux
cmd-line-utils/readline/display.c:
Get rid of compiler warnings
cmd-line-utils/readline/history.c:
Got rid of compiler warnings:
- Defining some strings as const
- Added cast
cmd-line-utils/readline/rlmbutil.h:
Added cast to get rid of compiler warnings
cmd-line-utils/readline/text.c:
Remove not needed initialization to get rid of compiler warnings
cmd-line-utils/readline/xmalloc.c:
Changed types to 'const char* to get rid of compiler warnings
configure.in:
Ensure that we use MariaDB as suffix
include/mysql/plugin.h:
Changed types to 'const unsigned char* to get rid of compiler warnings (in other parts of the code)
Change length for not \0 terminated string to size_t
include/mysql/plugin.h.pp:
Update related to plugin.h
libmysql/libmysql.c:
Fixed bug that caused core dump with newer gcc when strict aliasing is not turned off
mysql-test/t/information_schema.test:
Test is depending on innodb
mysql-test/t/not_partition.test:
Fixed wrong directory name
(Not noticed before as we don't ususally run this test)
mysys/lf_hash.c:
Got rid of compiler warnings from -Wstrict-aliasing
mysys/my_redel.c:
Removed not used variable
regex/engine.c:
Changed types to 'const char* to get rid of compiler warnings
regex/engine.ih:
Changed types to 'const char* to get rid of compiler warnings
sql/sp_head.cc:
Got rid of compiler warning from -Wstrict-aliasing
sql/sql_base.cc:
Got rid of compiler warnings from -Wstrict-aliasing
(The original code was probably wrong as nj_col->table_field was
sql/sql_builtin.cc.in:
plugin.h needs to have size_t defined
sql/sql_parse.cc:
Remove used variable
sql/sql_select.cc:
Got rid of compiler warnings from -Wstrict-aliasing
sql/sql_show.cc:
Added #ifdef to get rid of compiler warning when not using partition engine
sql/table.cc:
Got rid of compiler warning from -Wstrict-aliasing
storage/maria/ha_maria.cc:
Got rid of compiler warnings from -Wstrict-aliasing:
- Use the thd_killed() API function
storage/maria/lockman.c:
Got rid of compiler warnings from -Wstrict-aliasing
storage/maria/ma_check.c:
Got rid of compiler warnings from -Wstrict-aliasing
Change to use new version of _ma_killed_ptr; Don't call it as often as before
storage/maria/ma_check_standalone.h:
Update to compatible _ma_killed_ptr() from ha_maria.cc
storage/maria/ma_ft_boolean_search.c:
Changed pointers from char -> const char* and length to size_t (to get rid of compiler warnings and casts)
storage/maria/ma_ft_nlq_search.c:
Got rid of compiler warnings from -Wstrict-aliasing
Ensure that 'subkeys' is 32 bit
storage/maria/ma_ft_parser.c:
Changed pointers from char -> const char* and length to size_t (to get rid of compiler warnings and casts)
storage/maria/ma_ftdefs.h:
Changed pointers from char -> const char* and length to size_t (to get rid of compiler warnings and casts)
storage/maria/ma_sort.c:
Change to use new version of _ma_killed_ptr; Don't call it as often as before
storage/maria/ma_state.c:
Got rid of compiler warnings from -Wstrict-aliasing
storage/maria/maria_def.h:
Redefine ma_killed_ptr()
storage/maria/maria_ftdump.c:
Got rid of compiler warnings from -Wstrict-aliasing
storage/maria/trnman.c:
Got rid of compiler warnings from -Wstrict-aliasing
storage/myisam/ft_boolean_search.c:
Changed pointers from char -> const char* and length to size_t (to get rid of compiler warnings and casts)
storage/myisam/ft_nlq_search.c:
Got rid of compiler warnings from -Wstrict-aliasing
storage/myisam/ft_parser.c:
Changed pointers from char -> const char* and length to size_t (to get rid of compiler warnings and casts)
storage/myisam/ft_stopwords.c:
Changed pointers from char -> const char* and length to size_t (to get rid of compiler warnings and casts)
storage/myisam/ftdefs.h:
Changed pointers from char -> const char* and length to size_t (to get rid of compiler warnings and casts)
storage/myisam/ha_myisam.cc:
Got rid of compiler warnings from -Wstrict-aliasing:
- Use the thd_killed() API function
storage/myisam/mi_check.c:
Use new killed_ptr() function
storage/myisam/myisam_ftdump.c:
Got rid of compiler warnings from -Wstrict-aliasing
storage/myisam/myisamchk.c:
Update to compatible killed_ptr() from ha_myisam.cc
storage/myisam/myisamdef.h:
Redefine killed_ptr()
storage/myisam/myisamlog.c:
Got rid of compiler warnings from -Wstrict-aliasing
storage/myisam/sort.c:
Change to use new version of killed_ptr; Don't call it as often as before
storage/xtradb/fil/fil0fil.c:
Fixedc ompiler warning
storage/xtradb/trx/trx0i_s.c:
Include mysql_plugin.h later to ensure that size_t is defined
mysql-test/mysql-test-run.pl:
Manually apply similar patch to the one in Bug#47983.
mysql-test/suite/rpl/r/rpl_temporary_errors.result:
Fix wrong failure with warning in error log due to per-test suppressions
not being active during server shutdown.
mysql-test/suite/rpl/t/rpl_temporary_errors.test:
Fix wrong failure with warning in error log due to per-test suppressions
not being active during server shutdown.
sql/sql_select.cc:
Manually cherry-pick fix for Bug#45989.
For some reason, that fix was reverted in MySQL 5.1, even though it is
necessary to plug the memory leak.
Bug #48370 Absolutely wrong calculations with GROUP BY and
decimal fields when using IF
Added the test cases in the above two bugs for regression
testing.
Added additional tests that demonstrate a incomplete fix.
Added a new factory method for Field_new_decimal to
create a field from an (decimal returning) Item.
In the new method made sure that all the precision and
length variables are capped in a proper way.
This is required because Item's can have larger precision
than the decimal fields and thus need to be capped when
creating a field based on an Item type.
Fixed the wrong typecast to Item_decimal.
Not all my_hash_insert() calls are checked for return value.
This patch adds appropriate checks and failure responses
where needed.
mysys/hash.c:
* Debug hook for testing failures in my_hash_insert()
- Moved some code from innodb_plugin to xtradb, to ensure that all tests runs
- Did changes in pbxt and maria storage engines becasue of changes in thd->query
- Reverted wrong code in sql_table.cc for how ROW_FORMAT is used.
This is a re-commit of Monty's merge to eliminate an extra commit from
MySQL-5.1.42 that was accidentally included in the merge.
This is a merge of the MySQL 5.1.41 clone-off (clone-5.1.41-build). In
case there are any extra changes done before final MySQL 5.1.41
release, these will need to be merged later before MariaDB 5.1.41
release.
init_read_record() - (records.cc:274)
Item_cond::used_tables_cache was accessed in
records.cc#init_read_record() without being initialized. It had
not been initialized because it was wrongly assumed that the
Item's variables would not be accessed, and hence
quick_fix_field() was used instead of fix_fields() to save a few
CPU cycles at creation time.
The fix is to properly initilize the Item by replacing
quick_fix_field() with fix_fields().
mysql-test/r/select.result:
Add test for BUG#48052
mysql-test/t/select.test:
Add test for BUG#48052
sql/sql_select.cc:
Properly initialize Item_cond_and by calling fix_fields (instead of quick_fix_field) when the Item that "ANDs" WHERE clause conditions with HAVING clause conditions is created.
memory
The server was doing a bad class typecast causing setting of
wrong value for the maximum number of items in an internal
structure used in equality propagation.
Fixed by not doing the wrong typecast and asserting the type
of the Item where it should be done.
values
We should re-set the access method functions when changing the access
method when switching to another index to avoid sorting.
Fixed by doing a little re-engineering : encapsulating all the function
assignment into a special function and calling it when flipping the
indexes.
only const tables
The problem was caused by two shortcuts in the optimizer that
are inapplicable in the ROLLUP case.
Normally in a case when only const tables are involved in a
query, DISTINCT clause can be safely optimized away since there
may be only one row produced by the join. Similarly, we don't
need to create a temporary table to resolve DISTINCT/GROUP
BY/ORDER BY. Both of these are inapplicable when the WITH
ROLLUP modifier is present.
Fixed by disabling the said optimizations for the WITH ROLLUP
case.
mysql-test/r/olap.result:
Added a test case for bug #48475.
mysql-test/t/olap.test:
Added a test case for bug #48475.
sql/sql_select.cc:
Disabled const-only table optimizations for the WITH ROLLUP
case.
