MySQL Bugs: #35546: mysqlbinlog.cc: Load_log_processor::process_first

Bug #35546	mysqlbinlog.cc: Load_log_processor::process_first_event() fails creating unique
Submitted:	25 Mar 2008 10:38	Modified:	1 Feb 2009 18:40
Reporter:	Andrei Elkin	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: Replication	Severity:	S3 (Non-critical)
Version:	6.0	OS:	Any
Assigned to:	Andrei Elkin	CPU Architecture:	Any
Tags:	mysqlbinlog temp_file_path

Description:
file name.

Observed as a failure with binlog_killed_simulate on pushbild:

https://intranet.mysql.com/secure/pushbuild/getlog.pl?dir=mysql-6.0&entry=anozdrin%40quad....

ERROR: Could not construct local filename /tmp/SQL_LOAD_MB comes from
mysqlbinlog.cc 
Exit_status Load_log_processor::process_first_event()

...
  if ((file= create_unique_file(fname,ptr)) < 0)
  {
    error("Could not construct local filename %s%s.",
          target_dir_name,bname);

How to repeat:
observe pb logs for binlog.binlog_killed_simulate

Suggested fix:
Most probable reason is non-permitted directory for the temp file arg of
create_unique_file().

Looks like a duplicate of Bug#35543, Bug#34283 or Bug#33238. A common failure in this function happens when tmp fills up with > 1000 /tmp/SQL_LOAD_MB* files.

The reason of the bug is that mysqlbinlog does not always clean up so that
eventually the /tmp/ directory contains number of files sufficient to fail
the unique file name composing alg.

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/commits/46259

ChangeSet@1.2646, 2008-05-01 14:04:33+03:00, aelkin@mysql1000.dsl.inet.fi +2 -0
  Bug #35546 mysqlbinlog.cc: Load_log_processor::process_first_event() fails creating unique
  Bug #34283 mysqlbinlog leaves tmpfile after termination if binlog contains load data infile
  Bug #35543 mysqlbinlog.cc does not properly work with tmp files
  
  There were failures on pb executions in that mysqlbinlog could not compose a new 
  unique file name of its purpose.
  The reason of the bug has been that mysqlbinlog used the system wide temprorary directory instead
  of the specified by mtr so that mysqlbinlog's temporary files happened to be out of reach of mtr.
  
  Logics of the mysqlbinlog program correctly allows leaving new produced files such as ones that 
  hold LOAD DATA data.
  This is fine as long as a caller of mysqlbinlog takes care of the new files later.
  
  The problem fixed with specifying explicitly the temp directory for mysqlbinlog when it's called
  from mtr. New files mysqlbinlog can produce now reside in the mtr temporary directory.

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/commits/46311

ChangeSet@1.2646, 2008-05-02 21:32:15+03:00, aelkin@mysql1000.dsl.inet.fi +3 -0
  Bug #35546 mysqlbinlog.cc: Load_log_processor::process_first_event() fails creating unique
  Bug #35543 mysqlbinlog.cc does not properly work with tmp files
  
  There were failures on pb executions in that mysqlbinlog could not compose a new 
  unique file name of its purpose.
  The reason of the bug has been that mysqlbinlog used the system wide temprorary directory instead
  of the specified by mtr so that mysqlbinlog's temporary files happened to be out of reach of mtr.
  
  Logics of the mysqlbinlog program correctly allows leaving new produced files such as ones that 
  hold LOAD DATA data.
  This is fine as long as a caller of mysqlbinlog takes care of the new files later.
  
  The problem fixed with specifying explicitly the temp directory for mysqlbinlog when it's called
  from mtr. New files mysqlbinlog can produce now reside in the mtr temporary directory.
  
  Also there were memory leaks reported (bug#35543) which are fixed with finding out the sources and deploying
  freeing.

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/commits/46353

ChangeSet@1.2646, 2008-05-05 17:17:19+03:00, aelkin@mysql1000.dsl.inet.fi +3 -0
  Bug #35546 mysqlbinlog.cc: Load_log_processor::process_first_event() fails creating unique
  Bug #35543 mysqlbinlog.cc does not properly work with tmp files
  
  There were failures on pb executions in that mysqlbinlog could not compose a new 
  unique file name of its purpose.
  The reason of the bug has been that mysqlbinlog used the system wide temprorary directory instead
  of the specified by mtr so that mysqlbinlog's temporary files happened to be out of reach of mtr.
  
  Logics of the mysqlbinlog program correctly allows leaving new produced files such as ones that 
  hold LOAD DATA data.
  This is fine as long as a caller of mysqlbinlog takes care of the new files later.
  
  The problem fixed with specifying explicitly the temp directory for mysqlbinlog when it's called
  from mtr. New files mysqlbinlog can produce now reside in the mtr temporary directory.
  
  Also there were memory leaks reported (bug#35543) which are fixed with finding out the sources and deploying
  freeing.

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/commits/46381

ChangeSet@1.2646, 2008-05-06 15:22:50+03:00, aelkin@mysql1000.dsl.inet.fi +3 -0
  Bug #35546 mysqlbinlog.cc: Load_log_processor::process_first_event() fails creating unique
  Bug #35543 mysqlbinlog.cc does not properly work with tmp files
  
  There were failures on pb executions in that mysqlbinlog could not compose a new 
  unique file name of its purpose.
  The reason of the bug has been that mysqlbinlog used the system wide temprorary directory instead
  of the specified by mtr so that mysqlbinlog's temporary files happened to be out of reach of mtr.
  
  Logics of the mysqlbinlog program correctly allows leaving new produced files such as ones that 
  hold LOAD DATA data.
  This is fine as long as a caller of mysqlbinlog takes care of the new files later.
  
  The problem fixed with specifying explicitly the temp directory for mysqlbinlog when it's called
  from mtr. New files mysqlbinlog can produce now reside in the mtr temporary directory.
  
  Also there were memory leaks reported (bug#35543) which are fixed with finding out the sources and deploying
  freeing.

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/commits/46387

ChangeSet@1.2646, 2008-05-06 16:22:42+03:00, aelkin@mysql1000.dsl.inet.fi +3 -0
  Bug #35546 mysqlbinlog.cc: Load_log_processor::process_first_event() fails creating unique
  Bug #35543 mysqlbinlog.cc does not properly work with tmp files
  
  There were failures on pb executions in that mysqlbinlog could not compose a new 
  unique file name of its purpose.
  The reason of the bug has been that mysqlbinlog used the system wide temprorary directory instead
  of the specified by mtr so that mysqlbinlog's temporary files happened to be out of reach of mtr.
  
  Logics of the mysqlbinlog program correctly allows leaving new produced files such as ones that 
  hold LOAD DATA data.
  This is fine as long as a caller of mysqlbinlog takes care of the new files later.
  
  The problem fixed with specifying explicitly the temp directory for mysqlbinlog when it's called
  from mtr. New files mysqlbinlog can produce now reside in the mtr temporary directory.
  
  Also there were memory leaks reported (bug#35543) which are fixed with finding out the sources and deploying
  freeing.

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/commits/46624

ChangeSet@1.2646, 2008-05-12 16:08:54+03:00, aelkin@mysql1000.dsl.inet.fi +3 -0
  Bug #35546 mysqlbinlog.cc: Load_log_processor::process_first_event() fails creating unique
  Bug #35543 mysqlbinlog.cc does not properly work with tmp files
  
  There were failures on pb executions in that mysqlbinlog could not compose a new 
  unique file name of its purpose.
  The reason of the bug has been that mysqlbinlog used the system wide temprorary directory instead
  of the specified by mtr so that mysqlbinlog's temporary files happened to be out of reach of mtr.
  
  Logics of the mysqlbinlog program correctly allows leaving new produced files such as ones that 
  hold LOAD DATA data.
  This is fine as long as a caller of mysqlbinlog takes care of the new files later.
  
  The problem fixed with specifying explicitly the temp directory for mysqlbinlog when it's called
  from mtr. New files mysqlbinlog can produce now reside in the mtr temporary directory.
  
  Also there were memory leaks reported (bug#35543) which are fixed with finding out the sources and deploying
  freeing.

Pushed to 6.0-rpl.

Pushed into 6.0.10-alpha (revid:luis.soares@sun.com-20090129165607-wiskabxm948yx463) (version source revid:luis.soares@sun.com-20090129163120-e2ntks4wgpqde6zt) (merge vers: 6.0.10-alpha) (pib:6)

Documented bugfix in the 6.0.10 changelog as follows:

        mysqlbinlog sometimes failed when trying to create temporary
        files; this was because it ignored the --tmpdir option and tried
        to use the system /tmp directory instead.

Also documented in the 5.6.0 changelog. See BUG#48463.

Moved 5.6.0 changelog entry to 5.5.3.