MySQL Bugs: #11286: yassl incompatible with "load data infile"

Bug #11286	yassl incompatible with "load data infile"
Submitted:	13 Jun 2005 11:24	Modified:	1 Sep 2005 14:14
Reporter:	Joerg Bruehe	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server	Severity:	S2 (Serious)
Version:	5.0.8-pre	OS:	various Unix
Assigned to:	Magnus Blåudd	CPU Architecture:	Any

Description:
Release build of 5.0.7, based on ChangeSet
  1.1955 05/06/10 21:31:39 kent@mysql.com +2 -0
  Merge mysql.com:/Users/kent/mysql/bk/mysql-4.1-gca
  into mysql.com:/Users/kent/mysql/bk/mysql-5.0-release

On ALL platforms where "yassl" was configured:
- FreeBSD 4.7 "cane" and 5.3 "bsd53",
- Linux on i686 "build", x86_64 "hammer", ia64 "quadita2",
several tests failed on the "load data infile" command like this:

rpl000001                      [ fail ]

Errors are (from /usr/home/mysqldev/bsd53/test/mysql-cluster-5.0.7-beta-freebsd5.3-i386/mysql-test/var/log/mysqltest-time) :
/usr/home/mysqldev/bsd53/test/mysql-cluster-5.0.7-beta-freebsd5.3-i386/bin/mysqltest: At line 6: query 'load data local infile '/usr/home/mysqldev/bsd53/test/mysql-cluster-5.0.7-beta-freebsd5.3-i386/mysql-test/std_data/words.dat' into table t1' failed: 1148: The used command is not allowed with this MySQL version
(the last lines may be the most important ones)

Ending Tests

How to repeat:
Build with yassl and test.

Suggested fix:
For 5.0.7: rebuild without yassl (just happening)

Why was that bug closed?
AIUI, the long term plan is to use yassl, so building without is just a bypass.

In a test build of 5.0.11, it re-occurred, but only is "yassl" was enabled.
Similar failures in tests "rpl000001" and "rpl_misc_functions"

rpl_loaddatalocal              [ fail ]

Errors are (from PATH/mysqltest-time) :
At line 26: query 'load data local infile './var/master-data/rpl_loaddatalocal.select_outfile' into table t1' failed: 1148: The used command is not allowed with this MySQL version
(the last lines may be the most important ones)

Ending Tests
===---===---===---===---===---===--- BUGDB:
===---===---===---===---===---===--- OCCURRED:
etpglb0-5.0-standard.log   normal
hp3750-5.0-standard.log   normal
hp3750-64bit-5.0-standard.log   normal
hpita2-64bit-5.0-standard.log   normal
hpux11-5.0-standard.log   normal
hpux11-64bit-5.0-standard.log   normal
sol10-sparc-a-64bit-5.0-standard.log   normal
sunfire100c-5.0-standard.log   normal
xserve-64bit-5.0-standard.log   normal

Trees saved as "tar.gz" files below "/nfstmp1/yassl/build-5.0.11/"

It's only incompatible with "load data local infile" and it seems to be by design since I found this comment in sql_parse.cc

"  Without SSL the handshake consists of one packet. This packet
  has both client capabilites and scrambled password.
  With SSL the handshake might consist of two packets. If the first
  packet (client capabilities) has CLIENT_SSL flag set, we have to
  switch to SSL and read the second packet. The scrambled password
  is in the second packet and client_capabilites field will be ignored.
  Maybe it is better to accept flags other than CLIENT_SSL from the
  second packet?  Without SSL the handshake consists of one packet. This packet
  has both client capabilites and scrambled password.
  With SSL the handshake might consist of two packets. If the first
  packet (client capabilities) has CLIENT_SSL flag set, we have to
  switch to SSL and read the second packet. The scrambled password
  is in the second packet and client_capabilites field will be ignored.
  Maybe it is better to accept flags other than CLIENT_SSL from the
  second packet?"

Will have a look if I can get client_capabilities from the "second" packet.

When mysqltest connects to the server an error occurs in SSL_do_handshake. mysqltest will then reconnect from the loop in safe_connect, unfortunately all settings are lost amongst other ssl settings and  MYSQL_OPT_LOCAL_INFILE. 

This has the effect that a connection without SSL and without LOCAL_INFILE support is setup between mysqltest and the server.

Adding CLIENT_REMEMBER_OPTIONS  to mysql_real_connect in safe_connect loop in mysqltest, will produce the error SSL connect failure, when enough number of retries has been attempted by the safe_connect loop.

Will continue to investigate cause of SSL_do_handshake failure.

To check if there are any data to read on the socket, the command "ioctl(socket_, FIONREAD, &ready);" is used. It does always return 0 in the ready variable on Solaris 10.

From http://developers.sun.com/solaris/developer/support/driver/wps/64bit/c0302.html

"FIONREAD
This ioctl returns the number of data bytes, in all data messages queued, in the location pointed to by the arg parameter. The ioctl returns a 32-bit quantity on to both 32-bit and 64-bit applications, so code that is passing the address of a long variable needs to be fixed to pass an int as part of its 64-bit cleaning. "

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/internals/29160

Pushed patch to 5.0.13

Noted in 5.0.13 changelog.