When fields are inserted instead of * in the select list they were not marked
for check for the ONLY_FULL_GROUP_BY mode.
The Field_iterator_table::create_item() function now marks newly created
items for check when in the ONLY_FULL_GROUP_BY mode.
The setup_wild() and the insert_fields() functions now maintain the
cur_pos_in_select_list counter for the ONLY_FULL_GROUP_BY mode.
In multi_update::send_data(), the counter of matched rows was not correctly incremented, when during insertion of a new row to a temporay table it had to be converted from HEAP to MyISAM.
This fix changes the logic to increment the counter of matched rows in the following cases:
1. If the error returned from write_row() is zero.
2. If the error returned from write_row() is non-zero, is neither HA_ERR_FOUND_DUPP_KEY nor HA_ERR_FOUND_DUPP_UNIQUE, and a call to create_myisam_from_heap() succeeds.
FORCE_INIT_OF_VARS was not defined for the
debug builds on Windows. This caused LINT_INIT
macro to be defined as NOP and this triggers
false alarms about use of uninitialized with
the runtime libs of some Visual Studio versions.
Fixed by defining FORCE_INIT_OF_VARS to match the
state of the Windows
This bug was intruduced by the fix for bug#17212 (in 4.1). It is not
ok to call test_if_skip_sort_order since this function will
alter the execution plan. By contract it is not ok to call
test_if_skip_sort_order in this context.
This bug appears only in the case when the optimizer has chosen
an index for accessing a particular table but finds a covering
index that enables it to skip ORDER BY. This happens in
test_if_skip_sort_order.
When merging views into the enclosing statement
the ORDER BY clause of the view is merged to the
parent's ORDER BY clause.
However when the VIEW is merged into an UNION
branch the ORDER BY should be ignored.
Use of ORDER BY for individual SELECT statements
implies nothing about the order in which the rows
appear in the final result because UNION by default
produces unordered set of rows.
Fixed by ignoring the ORDER BY clause from the merge
view when expanded in an UNION branch.
NULL MERGE: this ChangeSet will be null merged into mysql-5.1
Fixes:
- Bug #26662: mysqld assertion when creating temporary (InnoDB) table on a tmpfs filesystem
Fix by not open(2)ing with O_DIRECT but rather calling fcntl(2) to set
this flag immediately after open(2)ing. This way an error caused by
O_DIRECT not being supported can easily be ignored.
- Bug #23313: AUTO_INCREMENT=# not reported back for InnoDB tables
- Bug #21404: AUTO_INCREMENT value reset when Adding FKEY (or ALTER?)
Report the current value of the AUTO_INCREMENT counter to MySQL.
- Improve mysql_upgrade and add comments describing it's logic
- Don't look for mysql and mysqlcheck randomly, use dir where mysql_upgrade
was started from
- Don't look for mysql_fix_privilege_tables.sql randomly, compile
in the mysql_fix_privilege_tables.sql file and use that to upgrade
the system tables of MySQL
- Check for any unexpected error returned from runnning the mysql_fix_privilege_tables SQL
- Fix bug#26639, bug#24248 and bug#25405
conditions when executing an equijoin query with WHERE condition
containing a subquery predicate of the form join_attr NOT IN (SELECT ...).
To resolve a problem of the correct evaluation of the expression
attr NOT IN (SELECT ...)
an array of guards is created to make it possible to filter out some
predicates of the EXISTS subquery into which the original subquery
predicate is transformed, in the cases when a takes the NULL value.
If attr is defined as a field that cannot be NULL than such an array
is not needed and is not created.
However if the field a occurred also an an equijoin predicate t2.a=t1.b
and table t1 is accessed before table t2 then it may happen that the
the EXISTS subquery is pushed down to the condition evaluated just after
table t1 has been accessed. In this case any occurrence of t2.a is
substituted for t1.b. When t1.b takes the value of NULL an attempt is
made to turn on the corresponding guard. This action caused a crash as
no guard array had been created.
Now the code of Item_in_subselect::set_cond_guard_var checks that the guard
array has been created before setting a guard variable on. Otherwise the
method does nothing. It cannot results in returning a row that could be
rejected as the condition t2.a=t1.b will be checked later anyway.
