[MDEV-4718] Test "outfile_loaddata" fails on bigendian arches (ppc64) Created: 2013-06-26  Updated: 2013-07-02  Resolved: 2013-07-02

Status: Closed
Project: MariaDB Server
Component/s: None
Affects Version/s: 5.5.31
Fix Version/s: 5.5.32

Type: Bug Priority: Minor
Reporter: Honza Horak Assignee: Sergei Golubchik
Resolution: Fixed Votes: 0
Labels: None
Environment:

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.



 Comments   
Comment by Elena Stepanova [ 2013-06-28 ]

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.

Generated at Thu Feb 08 06:58:36 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.