"ctype_ucs.test" fails sporadically
Affects | Status | Importance | Assigned to | Milestone | ||
---|---|---|---|---|---|---|
Percona Server moved to https://jira.percona.com/projects/PS | Status tracked in 5.7 | |||||
5.5 |
Fix Released
|
High
|
Yura Sorokin | |||
5.6 |
Fix Released
|
High
|
Yura Sorokin | |||
5.7 |
Fix Released
|
High
|
Yura Sorokin |
Bug Description
"ctype_ucs.test" fails on 5.5 with the following output
------------
Comment:
Logfile:
CURRENT_TEST: main.ctype_ucs
--- /mnt/workspace/
+++ /mnt/workspace/
@@ -200,11 +200,14 @@
CREATE TABLE t1(a INT);
LOAD DATA INFILE 'tmpp.txt' INTO TABLE t1 CHARACTER SET ucs2
(@b) SET a=REVERSE(@b);
+Warnings:
+Warning 1366 Incorrect integer value: '?' for column 'a' at row 1
+Warning 1366 Incorrect integer value: '?' for column 'a' at row 2
# should return 2 zeroes (as the value is truncated)
SELECT * FROM t1;
a
0
-1
+0
DROP TABLE t1;
# Problem # 2 : if you write and read ucs2 data to a file they're lost
SELECT '00' UNION SELECT '10' INTO OUTFILE 'tmpp2.txt' CHARACTER SET ucs2;
mysqltest: Result content mismatch
------------
tags: | added: ci |
summary: |
- "ctype_ucs.test" fails sporadicaly + "ctype_ucs.test" fails sporadically |
The problem seems to be with "ctype_common.inc" file when included with the following variables set
******* ******* ******* ******* ******* *** _set= 'ucs2'; ctype_common. inc ******* ******* ******* ******* ***
SET @test_character
SET @test_collation= 'ucs2_general_ci';
-- source include/
*******
This include, although properly saves and restores all the session variables it uses, has one side effect. By changing the default database via "USE d1"/"USE test" this file implicitly changes "@@character_ set_database" session variable.
This variable, in turn, affects how string literals without explicit "_xxx" prefix are interpreted with regards to character set associated with them.
Therefore, "SELECT '00' UNION SELECT '10' INTO OUTFILE 'tmpp.txt'" from "ctype_ucs.test" will generate different files depending on whether "@@character_ set_database" is set to "ucs2" or "latin1".
According to the comment from the same file, the author of the original commit expected the select statement to produce two zeros (which means that he wanted 'tmpp.txt' to be written in 'latin1' encoding) ******* ******* ******* ******* ******* ******* ***** ******* ******* ******* ******* ******* ******* *****
*******
--echo # should return 2 zeroes (as the value is truncated)
SELECT * FROM t1;
*******
However, in the same commit we have different values recorded in "ctype_ucs.result" ******* ******* ******* ******* ******* ******* ***** ******* ******* ******* ******* ******* ******* *****
*******
# should return 2 zeroes (as the value is truncated)
SELECT * FROM t1;
a
0
1
*******