Workaround for a possible GCC bug happening in my_fill_ucs2:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58039
Commenting out the optimized loop.
Using the original MySQL version.
modified:
strings/ctype-ucs2.c
Problem:
=======
It was detected an incorrect behavior of my_strtoll10 function when
converting strings with numbers in the following format:
"184467440XXXXXXXXXYY"
Where XXXXXXXXX > 737095516 and YY <= 15
Samples of problematic numbers:
"18446744073709551915"
"18446744073709552001"
Instead of returning the larger unsigned long long value and setting overflow
in the returned error code, my_strtoll10 function returns the lower 64-bits
of the evaluated number and did not set overflow in the returned error code.
Analysis:
========
Once trying to fix bug 16820156, I've found this bug in the overflow check of
my_strtoll10 function.
This function, once receiving a string with an integer number larger than
18446744073709551615 (the larger unsigned long long number) should return the
larger unsigned long long number and set overflow in the returned error code.
Because of a wrong overflow evaluation, the function didn't catch the
overflow cases where (i == cutoff) && (j > cutoff2) && (k <= cutoff3). When
the overflow evaluation fails, the function return the lower 64-bits of the
evaluated number and do not set overflow in the returned error code.
Fix:
===
Corrected the overflow evaluation in my_strtoll10.
includes:
* remove some remnants of "Bug#14521864: MYSQL 5.1 TO 5.5 BUGS PARTITIONING"
* introduce LOCK_share, now LOCK_ha_data is strictly for engines
* rea_create_table() always creates .par file (even in "frm-only" mode)
* fix a 5.6 bug, temp file leak on dummy ALTER TABLE
WITH UTF8_UNICODE_CI COLLATION
Problem Description:
When comparing datetime values with strings, the utf8_unicode_ci collation
prevents correct comparisons. Consider the below set of queries, it is not
showing any results on a table which has tuples that satisfies the query.
But for collation utf8_general_ci it shows one tuple.
set names utf8 collate utf8_unicode_ci;;
select * from lang where dt='1979-12-09';
Analysis:
The comparison function is not chosen in case of collation utf8_unicode_ci.
In agg_item_set_converter() because the collation state is having
"MY_CS_NONASCII" for collation type "utf8_unicode_ci". The conversion
of the collation is happening for the date field. And because of that
it is unable to pickup proper compare function(i.e CMP_DATE_WITH_STR).
Actually the bug is accidentally introduced by the WL#3759 in 5.5.
And in 5.6 it is been fixed by the WL#3664.
Fix:
I have backported the changes from the file strings/ctype-uca.c which
are related to "utf8" introduced by the WL#3664.
This change helps in choosing the correct comparison function for all
the collations of utf8 charset.
Fixed OPTIMIZE with innodb
include/my_sys.h:
Removed ATTRIBUTE_FORMAT() as it gave warnings for %'s
sql/log_event.cc:
Optimization:
use my_b_write() and my_b_write_byte() instead of my_b_printf()
use strmake() instead of my_snprintf()
sql/sql_admin.cc:
Fixed bug in admin_recreate_table()
Fixed OPTIMIZE with innodb
sql/sql_table.cc:
Indentation fixes
strings/my_vsnprintf.c:
Changed fprintf() to fputs()
Bug#12608543: CRASHES WITH DECIMALS AND STATEMENT NEEDS TO BE REPREPARED ERRORS
Backporting these two fixes to 5.1
Added unittest to test my_decimal construtor and assignment operators
sql/my_decimal.h:
Added constructor and assignment operators for my_decimal
unittest/my_decimal/my_decimal-t.cc:
Added test to check constructor and assignment operators for my_decimal
Mini-benchmarking demonstrates up to 10% improvement in latin1->utf8
conversion.
modified:
@ strings/ctype-latin1.c
redundant test in ctype-latin1.c removed
@ strings/ctype-utf8.c
my_uni_utf8 rewritten in a more efficient way
Due to an internal change in the server code in between 5.1 and 5.5
(wl#2649) the hash function used in KEY partitioning changed
for numeric and date/time columns (from binary hash calculation
to character based hash calculation).
Also enum/set changed from latin1 ci based hash calculation to
binary hash between 5.1 and 5.5. (bug#11759782).
These changes makes KEY [sub]partitioned tables on any of
the affected column types incompatible with 5.5 and above,
since the calculation of partition id differs.
Also since InnoDB asserts that a deleted row was previously
read (positioned), the server asserts on delete of a row that
is in the wrong partition.
The solution for this situation is:
1) The partitioning engine will check that delete/update will go to the
partition the row was read from and give an error otherwise, consisting
of the rows partitioning fields. This will avoid asserts in InnoDB and
also alert the user that there is a misplaced row. A detailed error
message will be given, including an entry to the error log consisting
of both table name, partition and row content (PK if exists, otherwise
all partitioning columns).
2) A new optional syntax for KEY () partitioning in 5.5 is allowed:
[SUB]PARTITION BY KEY [ALGORITHM = N] (list_of_cols)
Where N = 1 uses the same hashing as 5.1 (Numeric/date/time fields uses
binary hashing, ENUM/SET uses charset hashing) N = 2 uses the same
hashing as 5.5 (Numeric/date/time fields uses charset hashing,
ENUM/SET uses binary hashing). If not set on CREATE/ALTER it will
default to 2.
This new syntax should probably be ignored by NDB.
3) Since there is a demand for avoiding scanning through the full
table, during upgrade the ALTER TABLE t PARTITION BY ... command is
considered a no-op (only .frm change) if everything except ALGORITHM
is the same and ALGORITHM was not set before, which allows manually
upgrading such table by something like:
ALTER TABLE t PARTITION BY KEY ALGORITHM = 1 () or
ALTER TABLE t PARTITION BY KEY ALGORITHM = 2 ()
4) Enhanced partitioning with CHECK/REPAIR to also check for/repair
misplaced rows. (Also works for ALTER TABLE t CHECK/REPAIR PARTITION)
CHECK FOR UPGRADE:
If the .frm version is < 5.5.3
and uses KEY [sub]partitioning
and an affected column type
then it will fail with an message:
KEY () partitioning changed, please run:
ALTER TABLE `test`.`t1` PARTITION BY KEY ALGORITHM = 1 (a)
PARTITIONS 12
(i.e. current partitioning clause, with the addition of
ALGORITHM = 1)
CHECK without FOR UPGRADE:
if MEDIUM (default) or EXTENDED options are given:
Scan all rows and verify that it is in the correct partition.
Fail for the first misplaced row.
REPAIR:
if default or EXTENDED (i.e. not QUICK/USE_FRM):
Scan all rows and every misplaced row is moved into its correct
partitions.
5) Updated mysqlcheck (called by mysql_upgrade) to handle the
new output from CHECK FOR UPGRADE, to run the ALTER statement
instead of running REPAIR.
This will allow mysql_upgrade (or CHECK TABLE t FOR UPGRADE) to upgrade
a KEY [sub]partitioned table that has any affected field type
and a .frm version < 5.5.3 to ALGORITHM = 1 without rebuild.
Also notice that if the .frm has a version of >= 5.5.3 and ALGORITHM
is not set, it is not possible to know if it consists of rows from
5.1 or 5.5! In these cases I suggest that the user does:
(optional)
LOCK TABLE t WRITE;
SHOW CREATE TABLE t;
(verify that it has no ALGORITHM = N, and to be safe, I would suggest
backing up the .frm file, to be used if one need to change to another
ALGORITHM = N, without needing to rebuild/repair)
ALTER TABLE t <old partitioning clause, but with ALGORITHM = N>;
which should set the ALGORITHM to N (if the table has rows from
5.1 I would suggest N = 1, otherwise N = 2)
CHECK TABLE t;
(here one could use the backed up .frm instead and change to a new N
and run CHECK again and see if it passes)
and if there are misplaced rows:
REPAIR TABLE t;
(optional)
UNLOCK TABLES;
It is a workaround that allows myodbc built by certain distributions' (CentOS,Fedora) to peacefully coexist with mariadb client libraries.
The problem is that MyODBC in these distros needs strmov() to be exported by mysql client shared library, or else myodbc fails to load.
frac is the number of decimal digits after the point
For each multiplication in the expression, decimal_mul() does this:
to->frac= from1->frac + from2->frac; /* store size in digits */
which will eventually overflow.
The code for handling the overflow, will truncate the two digits in "1.75" to "1"
Solution:
Truncate to 31 significant fractional digits, when doing decimal multiplication.
