BUG#45292 orphan binary log created when starting server twice

This patch fixes three bugs as follows. First, aborting the server while purging
binary logs might generate orphan files due to how the purge operation was
implemented:

          (purge routine - sql/log.cc - MYSQL_BIN_LOG::purge_logs)

      1 - register the files to be removed in a temporary buffer.
      2 - update the log-bin.index.
      3 - flush the log-bin.index.
      4 - erase the files whose names where register in the temporary buffer
      in step 1.

Thus a failure while  executing step 4 would generate an orphan file. Second,
a similar issue might happen while creating a new binary as follows:

          (create routine - sql/log.cc - MYSQL_BIN_LOG::open)

      1 - open the new log-bin.
      2 - update the log-bin.index.

Thus a failure while executing step 1 would generate an orphan file.

To fix these issues, we record the files to be purged or created before really
removing or adding them. So if a failure happens such records can be used to
automatically remove dangling files. The new steps might be outlined as follows:

          (purge routine - sql/log.cc - MYSQL_BIN_LOG::purge_logs)

      1 - register the files to be removed in the log-bin.~rec~ placed in
      the data directory.
      2 - update the log-bin.index.
      3 - flush the log-bin.index.
      4 - delete the log-bin.~rec~.

          (create routine - sql/log.cc - MYSQL_BIN_LOG::open)

      1 - register the file to be created in the log-bin.~rec~
      placed in the data directory.
      2 - open the new log-bin.
      3 - update the log-bin.index.
      4 - delete the log-bin.~rec~.

          (recovery routine - sql/log.cc - MYSQL_BIN_LOG::open_index_file)

      1 - open the log-bin.index.
      2 - open the log-bin.~rec~.
      3 - for each file in log-bin.~rec~.
        3.1 Check if the file is in the log-bin.index and if so ignore it.
        3.2 Otherwise, delete it.

The third issue can be described as follows. The purge operation was allowing
to remove a file in use thus leading to the loss of data and possible
inconsistencies between the master and slave. Roughly, the routine was only
taking into account the dump threads and so if a slave was not connect the
file might be delete even though it was in use.

1 files changed, 2 insertions, 2 deletions

diff --git a/sql/rpl_rli.cc b/sql/rpl_rli.cc
index a26717d7acf..66de9357a53 100644
--- a/sql/rpl_rli.cc
+++ b/sql/rpl_rli.cc
@@ -182,10 +182,10 @@ a file name for --relay-log-index option", opt_relaylog_index_name);
       note, that if open() fails, we'll still have index file open
       but a destructor will take care of that
     */
-    if (rli->relay_log.open_index_file(opt_relaylog_index_name, ln) ||
+    if (rli->relay_log.open_index_file(opt_relaylog_index_name, ln, TRUE) ||
         rli->relay_log.open(ln, LOG_BIN, 0, SEQ_READ_APPEND, 0,
                             (max_relay_log_size ? max_relay_log_size :
-                            max_binlog_size), 1))
+                            max_binlog_size), 1, TRUE))
     {
       pthread_mutex_unlock(&rli->data_lock);
       sql_print_error("Failed in open_log() called from init_relay_log_info()");