Details
-
Bug
-
Status: Closed (View Workflow)
-
Minor
-
Resolution: Fixed
-
5.5.31
-
None
-
None
-
Linux, ppc64
Description
I'm experiencing this problem with mariadb-5.5.31 on ppc64:
main.outfile_loaddata [ fail ]
|
Test ended at 2013-06-26 10:42:31
|
|
|
CURRENT_TEST: main.outfile_loaddata
|
--- /home/hhorak/rpmbuild/BUILD/mariadb-5.5.31-bad/mysql-test/r/outfile_loaddata.result 2013-05-21 18:09:51.000000000 -0400
|
+++ /home/hhorak/rpmbuild/BUILD/mariadb-5.5.31-bad/mysql-test/r/outfile_loaddata.reject 2013-06-26 10:42:30.982084691 -0400
|
@@ -143,15 +143,8 @@
|
LOAD DATA INFILE 'MYSQLTEST_VARDIR/tmp/t1.txt' INTO TABLE t2 CHARACTER SET binary FIELDS TERMINATED BY 'ъ';
|
Warnings:
|
Warning 1638 Non-ASCII separator arguments are not fully supported
|
-Warning 1265 Data truncated for column 'a' at row 1
|
-Warning 1261 Row 1 doesn't contain data for all columns
|
-Warning 1261 Row 1 doesn't contain data for all columns
|
-Warning 1265 Data truncated for column 'a' at row 2
|
-Warning 1261 Row 2 doesn't contain data for all columns
|
-Warning 1261 Row 2 doesn't contain data for all columns
|
SELECT * FROM t1 UNION SELECT * FROM t2 ORDER BY a, b, c;
|
a b c
|
-1 NULL NULL
|
1 ABC-АБВ DEF-ÂÃÄ
|
2 NULL NULL
|
SELECT * FROM t1 INTO OUTFILE 'MYSQLTEST_VARDIR/tmp/t1.txt' LINES STARTING BY 'ъ';
|
@@ -181,7 +174,6 @@
|
SELECT * FROM t1 UNION SELECT * FROM t2 ORDER BY a, b, c;
|
a b c
|
1 ABC-АБВ DEF-ÂÃÄ
|
-1 ABC-АБВ DEF-ÂÃÄÑŠ2
|
2 NULL NULL
|
# Default (binary) charset:
|
SELECT * INTO OUTFILE 'MYSQLTEST_VARDIR/tmp/t1.txt' FROM t1;
|
|
|
mysqltest: Result length mismatch
|
I'm reporting this issue mostly because I think that ppc64 actually behaves correctly, while all other architectures don't and what's more – even .result file is generated incorrectly.
The reason why I'm assuming that is straightly visible from the diff above – we have a valid cvs file (just generated) with multi-byte character as a separator. But we are not possible to load the data back – we get errors "Warning 1261 Row 1 doesn't contain data for all columns" and similar, which shouldn't be there at all in .results file.
To my understanding, the excuse for the "usual" (non-ppc64) behavior is given in the very first warning "Non-ASCII separator arguments are not fully supported", and the remaining oddities are caused by this partial support.
Test creators expected "main" platforms to behave like that, that's why the result file is written with these results and warnings.
On Solaris, the test is known to fail, so they simply added it to "experimental on solaris" list.
So, it seems our options aren't great:
1) to implement the rest of support for non-ascii separator arguments – frankly i doubt we have resources for that, unless of course it's a 10-min work;
2) to add "ppc64" marker to the experimental file – but then you'll still need to run tests with --experimental=.. and ignore exp-fail failures, which you probably don't do now;
3) to create "not_ppc64.inc" and "ppc64.inc" include files, and start adding them to tests like this.
I'm passing it over to Sergei to decide.
Sergei,
If it we want (2) or (3), please feel free to reassign back to me, but i'll need a machine to experiment.