This bug may manifest itself not only with the queries for which
the index-merge access method is chosen. It also may display
itself for queries with DISTINCT.
The bug was in how the Unique::get method used the merge_buffers
function. To compare elements in the the queue employed by
merge_buffers() it must use the buffpek_compare function rather
than the function for binary comparison.
Test that we can start a MySQL Server with a default multibyte charset with
NDB running. Test *really* basic functionality too.
Index: ndb-work/mysql-test/r/rpl_ndb_ctype_ucs2_def.result
===================================================================
previous correction didn't. make sure "tail" is fixed up
when filling cache several times; rework formulae.
---
Merge sin.intern.azundris.com:/home/tnurnberg/22540/50-22540
into sin.intern.azundris.com:/home/tnurnberg/22540/51-22540
When a UNION statement forced conversion of an UTF8
charset value to a binary charset value, the byte
length of the result values was truncated to the
CHAR_LENGTH of the original UTF8 value.
spaces.
When the my_strnncollsp_simple function compares two strings and one is a prefix
of another then this function compares characters in the rest of longer key
with the space character to find whether the longer key is greater or less.
But the sort order of the collation isn't used in this comparison. This may
lead to a wrong comparison result, wrongly created index or wrong order of the
result set of a query with the ORDER BY clause.
Now the my_strnncollsp_simple function uses collation sort order to compare
the characters in the rest of longer key with the space character.
1. Fix ddl_i18n_koi8r, ddl_i18n_utf8: explicitly specify character-sets
directory for mysqldump;
2. Fix crash in mysqldump if collation is not found;
3. Use proper way to compare character set names.
query / no aggregate of subquery
The optimizer counts the aggregate functions that
appear as top level expressions (in all_fields) in
the current subquery. Later it makes a list of these
that it uses to actually execute the aggregates in
end_send_group().
That count is used in several places as a flag whether
there are aggregates functions.
While collecting the above info it must not consider
aggregates that are not aggregated in the current
context. It must treat them as normal expressions
instead. Not doing that leads to incorrect data about
the query, e.g. running a query that actually has no
aggregate functions as if it has some (and hence is
expected to return only one row).
Fixed by ignoring the aggregates that are not aggregated
in the current context.
One other smaller omission discovered and fixed in the
process : the place of aggregation was not calculated for
user defined functions. Fixed by calling
Item_sum::init_sum_func_check() and
Item_sum::check_sum_func() as it's done for the rest of
the aggregate functions.
"Federared Transactions Failure"
Bug occurs when the user performs an operation which inserts more than
one row into the federated table and the federated table references a
remote table stored within a transactional storage engine. When the
insert operation for any one row in the statement fails due to
constraint violation, the federated engine is unable to perform
statement rollback and so the remote table contains a partial commit.
The user would expect a statement to perform the same so a statement
rollback is expected.
This bug was fixed by implementing bulk-insert handling into the
federated storage engine. This will relieve the bug for most common
situations by enabling the generation of a multi-row insert into the
remote table and thus permitting the remote table to perform
statement rollback when neccessary.
The multi-row insert is limited to the maximum packet size between
servers and should the size overflow, more than one insert statement
will be sent and this bug will reappear. Multi-row insert is disabled
when an "INSERT...ON DUPLICATE KEY UPDATE" is being performed.
The bulk-insert handling will offer a significant performance boost
when inserting a large number of small rows.
This patch builds on Bug29019 and Bug25511
"Federated INSERT failures"
Federated does not correctly handle "INSERT...ON DUPLICATE KEY UPDATE"
However, implementing such support is not reasonably possible without
increasing complexity of the storage engine: checking that constraints
on remote server match local server and parsing error messages.
This patch causes 'ON DUPLICATE KEY' to fail with ER_DUP_KEY message
if a conflict occurs and not to fail silently.
