An error occurred fetching the project authors.
  1. 23 Nov, 2009 1 commit
    • Konstantin Osipov's avatar
      Backport of: · 7edfae4e
      Konstantin Osipov authored
      -------------------------------------------------------------
      revno: 2877
      committer: Davi Arnaut <Davi.Arnaut@Sun.COM>
      branch nick: 35164-6.0
      timestamp: Wed 2008-10-15 19:53:18 -0300
      message:
      Bug#35164: Large number of invalid pthread_attr_setschedparam calls
      Bug#37536: Thread scheduling causes performance degradation at low thread count
      Bug#12702: Long queries take 100% of CPU and freeze other applications under Windows
      
      The problem is that although having threads with different priorities
      yields marginal improvements [1] in some platforms [2], relying on some
      statically defined priorities (QUERY_PRIOR and WAIT_PRIOR) to play well
      (or to work at all) with different scheduling practices and disciplines
      is, at best, a shot in the dark as the meaning of priority values may
      change depending on the scheduling policy set for the process.
      
      Another problem is that increasing priorities can hurt other concurrent
      (running on the same hardware) applications (such as AMP) by causing
      starvation problems as MySQL threads will successively preempt lower
      priority processes. This can be evidenced by Bug#12702.
      
      The solution is to not change the threads priorities and rely on the
      system scheduler to perform its job. This also enables a system admin
      to increase or decrease the scheduling priority of the MySQL process,
      if intended.
      
      Furthermore, the internal wrappers and code for changing the priority
      of threads is being removed as they are now unused and ancient.
      
      1. Due to unintentional side effects. On Solaris this could artificially
      help benchmarks as calling the priority changing syscall millions of
      times is more beneficial than the actual setting of the priority.
      
      2. Where it actually works. It has never worked on Linux as the default
      scheduling policy SCHED_OTHER only accepts the static priority 0.
      7edfae4e
  2. 30 Oct, 2009 1 commit
  3. 21 Oct, 2009 1 commit
    • Konstantin Osipov's avatar
      Backport of revno 2630.28.10, 2630.28.31, 2630.28.26, 2630.33.1, · d4632dff
      Konstantin Osipov authored
      2630.39.1, 2630.28.29, 2630.34.3, 2630.34.2, 2630.34.1, 2630.29.29,
      2630.29.28, 2630.31.1, 2630.28.13, 2630.28.10, 2617.23.14 and
      some other minor revisions.
      
      This patch implements: 
      
      WL#4264 "Backup: Stabilize Service Interface" -- all the
      server prerequisites except si_objects.{h,cc} themselves (they can
      be just copied over, when needed).
      
      WL#4435: Support OUT-parameters in prepared statements.
      
      (and all issues in the initial patches for these two
      tasks, that were discovered in pushbuild and during testing).
      
      Bug#39519: mysql_stmt_close() should flush all data
      associated with the statement.
      
      After execution of a prepared statement, send OUT parameters of the invoked
      stored procedure, if any, to the client.
      
      When using the binary protocol, send the parameters in an additional result
      set over the wire.  When using the text protocol, assign out parameters to
      the user variables from the CALL(@var1, @var2, ...) specification.
      
      The following refactoring has been made:
        - Protocol::send_fields() was renamed to Protocol::send_result_set_metadata();
        - A new Protocol::send_result_set_row() was introduced to incapsulate
          common functionality for sending row data.
        - Signature of Protocol::prepare_for_send() was changed: this operation
          does not need a list of items, the number of items is fully sufficient.
      
      The following backward incompatible changes have been made:
        - CLIENT_MULTI_RESULTS is now enabled by default in the client;
        - CLIENT_PS_MULTI_RESUTLS is now enabled by default in the client.
      d4632dff
  4. 16 Oct, 2009 1 commit
    • Georgi Kodinov's avatar
      Bug #40877: multi statement execution fails in 5.1.30 · 8f6f3dba
      Georgi Kodinov authored
            
      Implemented the server infrastructure for the fix:
      
      1. Added a function LEX_STRING *thd_query_string(THD) to return
      a LEX_STRING structure instead of char *.
      This is the function that must be called in innodb instead of 
      thd_query()
      
      2. Did some encapsulation in THD : aggregated thd_query and 
      thd_query_length into a LEX_STRING and made accessor and mutator 
      methods for easy code updating. 
      
      3. Updated the server code to use the new methods where applicable.
      8f6f3dba
  5. 14 Oct, 2009 1 commit
    • 's avatar
      Bug#46640: output from mysqlbinlog command in 5.1 breaks replication · 0ece5891
      authored
            
      The BINLOG statement was sharing too much code with the slave SQL thread, introduced with
      the patch for Bug#32407. This caused statements to be logged with the wrong server_id, the
      id stored inside the events of the BINLOG statement rather than the id of the running 
      server.
            
      Fix by rearranging code a bit so that only relevant parts of the code are executed by
      the BINLOG statement, and the server_id of the server executing the statements will 
      not be overrided by the server_id stored in the 'format description BINLOG statement'.
      0ece5891
  6. 09 Oct, 2009 1 commit
  7. 02 Oct, 2009 1 commit
  8. 01 Oct, 2009 1 commit
  9. 30 Sep, 2009 2 commits
    • Alfranio Correia's avatar
      BUG#43075 rpl.rpl_sync fails sporadically on pushbuild · 9682ff8a
      Alfranio Correia authored
      NOTE: Backporting the patch to next-mr.
            
      The slave was crashing while failing to execute the init_slave() function.
            
      The issue stems from two different reasons:
            
      1 - A failure while allocating the master info structure generated a
          segfault due to a NULL pointer.
            
      2 - A failure while recovering generated a segfault due to a non-initialized
          relay log file. In other words, the mi->init and rli->init were both set to true
          before executing the recovery process thus creating an inconsistent state as the
          relay log file was not initialized.
            
      To circumvent such problems, we refactored the recovery process which is now executed
      while initializing the relay log. It is ensured that the master info structure is
      created before accessing it and any error is propagated thus avoiding to set mi->init
      and rli->init to true when for instance the relay log is not initialized or the relay
      info is not flushed.
            
      The changes related to the refactory are described below:
            
      1 - Removed call to init_recovery from init_slave.
            
      2 - Changed the signature of the function init_recovery.
            
      3 - Removed flushes. They are called while initializing the relay log and master
          info.
            
      4 - Made sure that if the relay info is not flushed the mi-init and rli-init are not
          set to true.
            
      In this patch, we also replaced the exit(1) in the fault injection by DBUG_ABORT()
      to make it compliant with the code guidelines.
      9682ff8a
    • Davi Arnaut's avatar
      Bug#47525: MySQL crashed (Federated) · d941a1f3
      Davi Arnaut authored
      On Mac OS X or Windows, sending a SIGHUP to the server or a
      asynchronous flush (triggered by flush_time), would cause the
      server to crash.
      
      The problem was that a hook used to detach client API handles
      wasn't prepared to handle cases where the thread does not have
      a associated session.
      
      The solution is to verify whether the thread has a associated
      session before trying to detach a handle.
      d941a1f3
  10. 29 Sep, 2009 3 commits
    • Alfranio Correia's avatar
      BUG#40337 Fsyncing master and relay log to disk after every event is too slow · a48ff220
      Alfranio Correia authored
      NOTE: Backporting the patch to next-mr.
            
      The fix proposed in BUG#35542 and BUG#31665 introduces a performance issue
      when fsyncing the master.info, relay.info and relay-log.bin* after #th events.
      Although such solution has been proposed to reduce the probability of corrupted
      files due to a slave-crash, the performance penalty introduced by it has
      made the approach impractical for highly intensive workloads.
            
      In a nutshell, the option --syn-relay-log proposed in BUG#35542 and BUG#31665
      simultaneously fsyncs master.info, relay-log.info and relay-log.bin* and
      this is the main source of performance issues.
            
      This patch introduces new options that give more control to the user on
      what should be fsynced and how often:
            
         1) (--sync-master-info, integer) which syncs the master.info after #th event;
         2) (--sync-relay-log, integer) which syncs the relay-log.bin* after #th
         events.
         3) (--sync-relay-log-info, integer) which syncs the relay.info after #th
         transactions.
            
         To provide both performance and increased reliability, we recommend the following
         setup:
            
         1) --sync-master-info = 0 eventually the operating system will fsync it;
         2) --sync-relay-log = 0 eventually the operating system will fsync it;
         3) --sync-relay-log-info = 1 fsyncs it after every transaction;
            
      Notice, that the previous setup does not reduce the probability of
      corrupted master.info and relay-log.bin*. To overcome the issue, this patch also
      introduces a recovery mechanism that right after restart throws away relay-log.bin*
      retrieved from a master and updates the master.info based on the relay.info:
            
            
         4) (--relay-log-recovery, boolean) which enables a recovery mechanism that
         throws away relay-log.bin* after a crash.
            
      However, it can only recover the incorrect binlog file and position in master.info,
      if other informations (host, port password, etc) are corrupted or incorrect,
      then this recovery mechanism will fail to work.
      a48ff220
    • Andrei Elkin's avatar
      WL#342 heartbeat · 8acf951e
      Andrei Elkin authored
      Improving an error report generating.
      8acf951e
    • Andrei Elkin's avatar
      WL#342 heartbeat · c03549bf
      Andrei Elkin authored
      backporting from 6.0 code base to 5.1.
      c03549bf
  11. 26 Sep, 2009 1 commit
  12. 23 Sep, 2009 2 commits
  13. 18 Sep, 2009 1 commit
    • 's avatar
      Bug #42914 Log event that larger than max_allowed_packet results in stop of slave I/O thread, · 7079338e
      authored
                 But there is no Last_IO_Error reported.
      
      On the master, if a binary log event is larger than max_allowed_packet,
      ER_MASTER_FATAL_ERROR_READING_BINLOG and the specific reason of this error is
      sent to a slave when it requests a dump from the master, thus leading
      the I/O thread to stop.
      
      On a slave, the I/O thread stops when receiving a packet larger than max_allowed_packet.
      
      In both cases, however, there was no Last_IO_Error reported.
      
      This patch adds code to report the Last_IO_Error and exact reason before stopping the
      I/O thread and also reports the case the out memory pops up while
      handling packets from the master.
      7079338e
  14. 10 Sep, 2009 1 commit
    • Marc Alff's avatar
      WL#2110 (SIGNAL) · d5fd452d
      Marc Alff authored
      WL#2265 (RESIGNAL)
      
      Manual merge of SIGNAL and RESIGNAL to mysql-trunk-signal,
      plus required dependencies.
      d5fd452d
  15. 19 Aug, 2009 1 commit
    • Alfranio Correia's avatar
      BUG#45694 Deadlock in replicated statement is not retried · f132d6b4
      Alfranio Correia authored
      If the SQL Thread fails to execute an event due to a temporary error (e.g.
      ER_LOCK_DEADLOCK) and the option "--slave_transaction_retries" is set the SQL
      Thread should not be aborted and the transaction should be restarted from the
      beginning and re-executed.
      
      Unfortunately, a wrong interpretation of the THD::is_fatal_error was preventing
      this behavior. In a nutshell, "this variable is set to TRUE if an execution of a
      compound statement cannot continue. In particular, it is used to disable access
      to the CONTINUE or EXIT handlers of stored routines. So even temporary errors
      may have this variable set.
      
      To fix the bug, we have done what follows:
      
         DBUG_ENTER("has_temporary_error");
      
      -  if (thd->is_fatal_error)
      -    DBUG_RETURN(0);
      -
         DBUG_EXECUTE_IF("all_errors_are_temporary_errors",
                         if (thd->main_da.is_error())
                         {
      f132d6b4
  16. 13 Aug, 2009 1 commit
    • Davi Arnaut's avatar
      Bug#46013: rpl_extraColmaster_myisam fails on pb2 · 97dbd987
      Davi Arnaut authored
      Bug#45243: crash on win in sql thread clear_tables_to_lock() -> free()
      Bug#45242: crash on win in mysql_close() -> free()
      Bug#45238: rpl_slave_skip, rpl_change_master failed (lost connection) for STOP SLAVE
      Bug#46030: rpl_truncate_3innodb causes server crash on windows
      Bug#46014: rpl_stm_reset_slave crashes the server sporadically in pb2
      
      When killing a user session on the server, it's necessary to
      interrupt (notify) the thread associated with the session that
      the connection is being killed so that the thread is woken up
      if waiting for I/O. On a few platforms (Mac, Windows and HP-UX)
      where the SIGNAL_WITH_VIO_CLOSE flag is defined, this interruption
      procedure is to asynchronously close the underlying socket of
      the connection.
      
      In order to enable this schema, each connection serving thread
      registers its VIO (I/O interface) so that other threads can
      access it and close the connection. But only the owner thread of
      the VIO might delete it as to guarantee that other threads won't
      see freed memory (the thread unregisters the VIO before deleting
      it). A side note: closing the socket introduces a harmless race
      that might cause a thread attempt to read from a closed socket,
      but this is deemed acceptable.
      
      The problem is that this infrastructure was meant to only be used
      by server threads, but the slave I/O thread was registering the
      VIO of a mysql handle (a client API structure that represents a
      connection to another server instance) as a active connection of
      the thread. But under some circumstances such as network failures,
      the client API might destroy the VIO associated with a handle at
      will, yet the VIO wouldn't be properly unregistered. This could
      lead to accesses to freed data if a thread attempted to kill a
      slave I/O thread whose connection was already broken.
      
      There was a attempt to work around this by checking whether
      the socket was being interrupted, but this hack didn't work as
      intended due to the aforementioned race -- attempting to read
      from the socket would yield a "bad file descriptor" error.
      
      The solution is to add a hook to the client API that is called
      from the client code before the VIO of a handle is deleted.
      This hook allows the slave I/O thread to detach the active vio
      so it does not point to freed memory.
      97dbd987
  17. 24 Jul, 2009 1 commit
    • Gleb Shchepa's avatar
      Bug #38816: kill + flush tables with read lock + stored · 6aea4ceb
      Gleb Shchepa authored
                  procedures causes crashes!
      
      The problem of that bugreport was mostly fixed by the
      patch for bug 38691.
      However, attached test case focused on another crash or
      valgrind warning problem: SHOW PROCESSLIST query accesses
      freed memory of SP instruction that run in a parallel
      connection.
      
      Changes of thd->query/thd->query_length in dangerous
      places have been guarded with the per-thread
      LOCK_thd_data mutex (the THD::LOCK_delete mutex has been
      renamed to THD::LOCK_thd_data).
      6aea4ceb
  18. 17 Jul, 2009 1 commit
  19. 16 Jul, 2009 1 commit
    • 's avatar
      Bug #45214 get_master_version_and_clock does not report error when queries fail · 8fb14b6d
      authored
              
      The "get_master_version_and_clock(...)" function in sql/slave.cc ignores 
      error and passes directly when queries fail, or queries succeed 
      but the result retrieved is empty.
        
      The "get_master_version_and_clock(...)" function should try to reconnect master
      if queries fail because of transient network problems, and fail otherwise.
      The I/O thread should print a warning if the some system variables do not 
      exist on master (very old master)
      8fb14b6d
  20. 06 Jul, 2009 1 commit
    • Alfranio Correia's avatar
      BUG#44581 Slave stops when transaction with non-transactional table gets lock wait · 508fe9dd
      Alfranio Correia authored
      timeout
                  
      In STMT and MIXED modes, a statement that changes both non-transactional and
      transactional tables must be written to the binary log whenever there are
      changes to non-transactional tables. This means that the statement gets into the
      binary log even when the changes to the transactional tables fail. In particular
      , in the presence of a failure such statement is annotated with the error number
      and wrapped in a begin/rollback. On the slave, while applying the statement, it
      is expected the same failure and the rollback prevents the transactional changes
      to be persisted.
                  
      Unfortunately, statements that fail due to concurrency issues (e.g. deadlocks,
      timeouts) are logged in the same way causing the slave to stop as the statements
      are applied sequentially by the SQL Thread. To fix this bug, we automatically
      ignore concurrency failures on the slave. Specifically, the following failures
      are ignored: ER_LOCK_WAIT_TIMEOUT, ER_LOCK_DEADLOCK and ER_XA_RBDEADLOCK.
      508fe9dd
  21. 29 Jun, 2009 1 commit
  22. 23 Jun, 2009 1 commit
    • Andrei Elkin's avatar
      Bug #38240 Crash in safe_mutex_lock () thr_mutex.c line 97 on rotate_relay_log · 0ecf826a
      Andrei Elkin authored
                  
      The reason for the crash was rotate_relay_log (mi=0x0) did not verify
      the passed value of active_mi.  There are more cases where active_mi
      is supposed to be non-zero e.g change_master(), stop_slave(), and it's
      reasonable to protect from a similar crash all of them with common
      fixes.
                  
      Fixed with spliting end_slave() in slave threads release and slave
      data clean-up parts (a new close_active_mi()). The new function is
      invoked at the very end of close_connections() so that all users of
      active_mi are proven to have left.
      0ecf826a
  23. 16 Jun, 2009 1 commit
  24. 09 Jun, 2009 2 commits
    • Staale Smedseng's avatar
      Bug #43414 Parenthesis (and other) warnings compiling MySQL · dae006c1
      Staale Smedseng authored
      with gcc 4.3.2
            
      Compiling MySQL with gcc 4.3.2 and later produces a number of 
      warnings, many of which are new with the recent compiler
      versions.
            
      This bug will be resolved in more than one patch to limit the
      size of changesets. This is the first patch, fixing a number 
      of the warnings, predominantly "suggest using parentheses 
      around && in ||", and empty for and while bodies.
      dae006c1
    • Staale Smedseng's avatar
      Bug #43414 Parenthesis (and other) warnings compiling MySQL · 53d9b3d9
      Staale Smedseng authored
      with gcc 4.3.2
      
      Compiling MySQL with gcc 4.3.2 and later produces a number of 
      warnings, many of which are new with the recent compiler
      versions.
      
      This bug will be resolved in more than one patch to limit the
      size of changesets. This is the first patch, fixing a number 
      of the warnings, predominantly "suggest using parentheses 
      around && in ||", and empty for and while bodies.
      53d9b3d9
  25. 03 Jun, 2009 1 commit
    • Luis Soares's avatar
      BUG#44270: RESET SLAVE does not reset Last_IO_Error or Last_IO_Errno · e6f15deb
      Luis Soares authored
      The server was not cleaning the last IO error and error number when
      resetting slave.
      
      This patch addresses this issue by backporting into 5.1 part of the
      patch in BUG 34654. A fix for this issue had already been pushed into
      6.0 as part of the aforementioned bug, however the patch also included
      some refactoring. The fix for 5.1 does not take into account the
      refactoring part.
      e6f15deb
  26. 22 May, 2009 1 commit
    • Luis Soares's avatar
      BUG#41725: slave crashes when inserting into temporary table after · 2b4fcc1d
      Luis Soares authored
      stop/start slave
            
      When stopping and restarting the slave while it is replicating
      temporary tables, the server would crash or raise an assertion
      failure. This was due to the fact that although temporary tables are
      saved between slave threads restart, the reference to the thread in
      use (table->in_use) was not being properly updated when the restart
      happened (it would still reference the old/invalid thread instead of
      the new one).
            
      This patch addresses this issue by resetting the reference to the new
      slave thread on slave thread restart.
      2b4fcc1d
  27. 05 May, 2009 1 commit
  28. 04 May, 2009 1 commit
  29. 28 Apr, 2009 1 commit
    • Andrei Elkin's avatar
      Bug #38694 Race condition in replication thread shutdown · e02d162f
      Andrei Elkin authored
      The issue of the current bug is unguarded access to mi->slave_running 
      by the shutdown thread calling end_slave() that is bug#29968 
      (alas happened not to be cross-linked with the current bug)
      
      Fixed:
      
      with removing the unguarded read of the running status
      and perform reading it in terminate_slave_thread()
      at time run_lock is taken (mostly bug#29968 backporting, still with some
      improvements over that patch - see the error reporting from 
      terminate_slave_thread()).
      Issue of bug#38716 is fixed here for 5.0 branch as well.
      
      Note:
      
      There has been a separate artifact identified - 
      a race condition between init_slave() and  end_slave() - 
      reported as  Bug#44467.
      e02d162f
  30. 19 Apr, 2009 1 commit
    • Alfranio Correia's avatar
      BUG#43949 Initialization of slave produces a warning message in Valgrind · 8caf4bfc
      Alfranio Correia authored
      In order to define the --slave-load-tmpdir, the init_relay_log_file()
      was calling fn_format(MY_PACK_FILENAME) which internally was indirectly
      calling strmov_overlapp() (through pack_dirname) and the following
      warning message was being printed out while running in Valgrind:
      "source and destination overlap in strcpy".
      
      We fixed the issue by removing the flag MY_PACK_FILENAME as it was not
      necessary. In a nutshell, with this flag the function fn_format() tried
      to replace a directory by either "~", "." or "..". However, we wanted
      exactly to remove such strings.
      
      In this patch, we also refactored the functions init_relay_log_file()
      and check_temp_dir(). The former was refactored to call the fn_format()
      with the flag MY_SAFE_PATH along with the MY_RETURN_REAL_PATH,  in order
      to avoid issues with long directories and return an absolute path,
      respectively. The flag MY_SAFE_UNPACK_FILENAME was removed too as it was
      responsible for removing "~", "." or ".." only from the file parameter
      and we wanted to remove such strings from the directory parameter in
      the fn_format(). This result is stored in an rli variable, which is then
      processed by the other function in order to verify if the directory exists
      and if we are able to create files in it.
      8caf4bfc
  31. 06 Apr, 2009 1 commit
    • Tatiana A. Nurnberg's avatar
      Bug#43835: SHOW VARIABLES does not include 0 for slave_skip_errors · 11f44544
      Tatiana A. Nurnberg authored
      We didn't expect "error: no error", although this is
      in fact a legitimate state (if something is erroneous
      on the master, but not on the slave, e.g. INSERT fails
      on master due to UNIQUE constraint which does not exist
      on slave).
      
      We now list the ignore for "0: no error" the same way
      as any other ignore; moreover, if no or an empty
      --slave-skip-errors is passed at start-up, we show
      "OFF" instead of empty list, as intended. (The code
      for that was there, but was only run for the empty-
      argument case, even if it subsequently tested for
      both conditions.) 
      11f44544
  32. 05 Apr, 2009 1 commit
    • Alfranio Correia's avatar
      BUG#39393 slave-skip-errors does not work when using ROW based replication · 1287d8c5
      Alfranio Correia authored
                                    
      RBR was not considering the option --slave-skip-errors.
                                    
      To fix the problem, we are reporting the ignored ERROR(s) as warnings thus avoiding 
      stopping the SQL Thread. Besides, it fixes the output of "SHOW VARIABLES LIKE 
      'slave_skip_errors'" which was showing nothing when the value "all" was assigned 
      to --slave-skip-errors.
                        
      @sql/log_event.cc
        skipped rbr errors when the option skip-slave-errors is set.
      @sql/slave.cc
        fixed the output of for SHOW VARIABLES LIKE 'slave_skip_errors'"
      @test-cases
        fixed the output of rpl.rpl_idempotency
        updated the test case rpl_skip_error
      1287d8c5
  33. 26 Mar, 2009 1 commit
    • Andrei Elkin's avatar
      Bug#38205 Row-based Replication (RBR) causes inconsistencies: HA_ERR_FOUND_DUP · badc6a12
      Andrei Elkin authored
      Bug#319  if while a non-transactional slave is replicating a transaction possible problem 
      
      It is impossible to roll back a mixed engines transaction when one of the engine is
      non-transaction. In replication that fact is crucial because the slave can not safely
      re-apply a transction that was interrupted with STOP SLAVE.
      
      Fixed with making STOP SLAVE not be effective immediately in the case the current
      group of replication events has modified a non-transaction table. In order for slave to leave
      either the group needs finishing or the user issues KILL QUERY|CONNECTION slave_thread_id.
      badc6a12
  34. 18 Mar, 2009 1 commit
    • Alfranio Correia's avatar
      Bug #42861 Assigning invalid directories to --slave-load-tmpdir crashes the slave · 2f16f070
      Alfranio Correia authored
      Compiling with debug and assigning an invalid directory to --slave-load-tmpdir
      was crashing the slave due to the following assertion DBUG_ASSERT(! is_set() ||
      can_overwrite_status). This assertion assumes that a thread can change its
      state once (i.e. ok,error, etc) before aborting, cleaning/resuming or completing
      its execution unless the overwrite flag (i.e. can_overwrite_status) is true.
      
      The Append_block_log_event::do_apply_event which is responsible for creating
      temporary file(s) was not cleaning the thread state. Thus a failure while
      trying to create a file in an invalid temporary directory was causing the crash.
      
      To fix the problem we check if the temporary directory is valid before starting
      the SQL Thread and reset the thread state before creating a file in
      Append_block_log_event::do_apply_event.
      2f16f070
  35. 11 Feb, 2009 1 commit
    • Alfranio Correia's avatar
      BUG#38197 Errors in @@init_slave not visible in 'show slave status' · 87679ac9
      Alfranio Correia authored
            
      Some errors that cause the slave SQL thread to stop are not shown in the
      Slave_SQL_Error column of "SHOW SLAVE STATUS". Instead, the error is only 
      in the server's error log.
            
      That makes it difficult to analyze the error for the user. One example of an error
      that stops the slave but is not shown by "SHOW SLAVE STATUS" is when @@global.init_slave
      is set incorrectly (e.g., it contains something that is not valid SQL).
            
      Three failures were not correctly reported:
            
      1 - Failures during slave thread initialization
      2 - Failures while initializing the relay log position right after
      starting the slave thread.
      3 - Failures while processing queries passed through the init_slave
      option.
            
      This patch fixes the issues by reporting the errors through relay-info->report.
      87679ac9