Re: bk commit into 6.0 tree (aelkin:1.2646) BUG#35546

[Davi Arnaut]

Andrei Elkin wrote:
> Below is the list of changes that have just been committed into a local
> 6.0 repository of aelkin.  When aelkin does a push these changes
> will be propagated to the main repository and, within 24 hours after the
> push, to the public repository.
> For information on how to access the public repository
> see http://dev.mysql.com/doc/mysql/en/installing-source-tree.html
> 
> ChangeSet@stripped, 2008-05-01 14:04:33+03:00, aelkin@stripped +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 just working around the issue. What happens in a non-mtr
environment? That tmp file creation function is unacceptable.

>   This is fine as long as a caller of mysqlbinlog takes care of the new files later.

OK, callers are responsible for cleaning up files left by mysqlbinlog.

How does a caller know which files mysqlbinlog created?

How the caller know which files are temporary?

How the caller know which files were created by the mysqlbinlog instance
he called?

IMHO, this is wrong. Temporary files should be erased by the one who
created it and not the caller.

>   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.

This is not a proper fix.

You also haven't fixed the other remarks on Bug#35543.

Regards,

-- 
Davi Arnaut, Software Engineer
MySQL Server Runtime Team
Database Group, Sun Microsystems