Bug #3422 In 3.23 -> 4.0 replication, slave segfault when replicating LOAD DATA INFILE
Submitted: 8 Apr 2004 9:14 Modified: 8 Apr 2004 13:34
Reporter: Guilhem Bichot Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: Replication Severity:S3 (Non-critical)
Version:4.0 OS:Any (all)
Assigned to: Guilhem Bichot CPU Architecture:Any

[8 Apr 2004 9:14] Guilhem Bichot 
Description:
It does not always happen, but Valgrind shows the use of uninitialized memory.

How to repeat:
Like in synopsis.

Suggested fix:
Will fix it today
[8 Apr 2004 13:34] Guilhem Bichot 
Thank you for your bug report. This issue has been committed to our
source repository of that product and will be incorporated into the
next release.

If necessary, you can access the source repository and build the latest
available version, including the bugfix, yourself. More information 
about accessing the source trees is available at
    http://www.mysql.com/doc/en/Installing_source_tree.html

Additional info:

Fixed in ChangeSet@1.1776, 2004-04-08 22:12:22+02:00, guilhem@mysql.com
Other problems remain with 3.23 -> 4.0 replication of LOAD DATA INFILE, I have added them to the documentation (in section "Replication features and known problems"):
"When a 4.x slave replicates a @code{LOAD DATA INFILE} from a 3.23
master, the values of the @code{Exec_Master_Log_Pos} and
@code{Relay_Log_Space} columns of @code{SHOW SLAVE STATUS} become
incorrect. The incorrectness of @code{Exec_Master_Log_Pos} will cause a
problem when you stop and restart replication; so it is a good idea to
correct the value before this, by doing @code{FLUSH LOGS} on the master.
These bugs are already fixed in MySQL 5.0.0 slaves."