Comment 13 for bug 375371

From http://dev.mysql.com/doc/refman/5.1/en/temporary-files.html

"A replication slave needs some of its temporary files to survive a machine restart so that it can replicate temporary tables or LOAD DATA INFILE operations. If files in the temporary file directory are lost when the server restarts, replication fails."

Because LOAD DATA INFILE checks for the killed flag while it is loading rows, it may stop mid-transaction, and leave the file in tmpdir. When the slave is started again, the file will still be there and the LOAD DATA INFILE command re-issued.

What I don't know is whether the binlog embeds @tmpdir/filename or /tmp/filename ... if its the former, then this is a problem, if its the latter, then we actually don't need to do it.

Assuming @tmpdir, its tricky but I think we can figure this out..

--preinst--
if there is a master.info in datadir (must be present on all slaves)
  figure out what old_tmpdir is
  stop mysql
  if $old_tmpdir != $new_tmpdir
    if find $old_tmpdir -user mysql -type f ; then
      LOW priority debconf question to ask whether to move the files to new tmpdir, with answer == Y?

--postinst--
if debconf answer to move files from old tmpdir was Y
  mv files to new tmpdir
start mysql

Another, simpler approach would be to just check for a running master in the preinst, and issue a warning advising the user to run 'SLAVE STOP' and ensure all files are cleared out from tmpdir before continuing.

One mitigating factor about this is that if we don't do anything, the slave will fail to start after the upgrade with a missing file in tmpdir, so the admin can resolve it fairly easily by manually moving the file at that time. Given that the changelog mentions the tmpdir change, and refers to this bug report, this isn't the worst thing in the world.