1. 27 Sep, 2006 3 commits
  2. 26 Sep, 2006 1 commit
  3. 25 Sep, 2006 1 commit
    • msvensson@neptunus.(none)'s avatar
      Bug #22379 im_daemon_life_cycle.test fails on merge of 5.1 -> 5.1-engines · d2ebe6be
      msvensson@neptunus.(none) authored
      Remove race situations that occur when removing pidfiles. Primarily each process should remove its own
      pidfile, secondly it should be removed by the process that created it and _only_ if it's
      certain the process is dead. Third, mysql-test-run.pl will remove the pidfile when process has been killed.
      - Set state of an instance to STARTING _before_ calling instance->start()
      - Check that pidfile of instance has been created before changing STARTING => STARTED
      - Only remove the pidfile if IM kills an instance with SIGKILL, otherwise the instance will remove it itself
      d2ebe6be
  4. 12 Sep, 2006 1 commit
    • kroki/tomash@moonlight.intranet's avatar
      BUG#21414: SP: Procedure undroppable, to some extent · ed0cb3e4
      kroki/tomash@moonlight.intranet authored
      The problem was that if after FLUSH TABLES WITH READ LOCK the user
      issued DROP/ALTER PROCEDURE/FUNCTION the operation would fail (as
      expected), but after UNLOCK TABLE any attempt to execute the same
      operation would lead to the error 1305 "PROCEDURE/FUNCTION does not
      exist", and an attempt to execute any stored function will also fail.
      
      This happened because under FLUSH TABLES WITH READ LOCK we couldn't open
      and lock mysql.proc table for update, and this fact was erroneously
      remembered by setting mysql_proc_table_exists to false, so subsequent
      statements believed that mysql.proc doesn't exist, and thus that there
      are no functions and procedures in the database.
      
      As a solution, we remove mysql_proc_table_exists flag completely.  The
      reason is that this optimization didn't work most of the time anyway.
      Even if open of mysql.proc failed for some reason when we were trying to
      call a function or a procedure, we were setting mysql_proc_table_exists
      back to true to force table reopen for the sake of producing the same
      error message (the open can fail for number of reasons).  The solution
      could have been to remember the reason why open failed, but that's a lot
      of code for optimization of a rare case.  Hence we simply remove this
      optimization.
      ed0cb3e4
  5. 11 Sep, 2006 1 commit
  6. 08 Sep, 2006 4 commits
  7. 07 Sep, 2006 5 commits
  8. 06 Sep, 2006 4 commits
  9. 05 Sep, 2006 2 commits
    • guilhem@gbichot3.local's avatar
      Fix for BUG#11151 "LOAD DATA INFILE commits transaction in 5.0". · e4d3595b
      guilhem@gbichot3.local authored
      In 5.0 we made LOAD DATA INFILE autocommit in all engines, while
      only NDB wanted that. Users and trainers complained that it affected
      InnoDB and was a change compared to 4.1 where only NDB autocommitted.
      To revert to the behaviour of 4.1, we move the autocommit logic out of mysql_load() into
      ha_ndbcluster::external_lock().
      The result is that LOAD DATA INFILE commits all uncommitted changes
      of NDB if this is an NDB table, its own changes if this is an NDB
      table, but does not affect other engines.
      Note: even though there is no "commit the full transaction at end"
      anymore, LOAD DATA INFILE stays disabled in routines (re-entrency
      problems per a comment of Pem).
      Note: ha_ndbcluster::has_transactions() does not give reliable results
      because it says "yes" even if transactions are disabled in this engine...
      e4d3595b
    • anozdrin/alik@alik.'s avatar
      Merge alik.:/mnt/raid/alik/MySQL/devel/5.0-tree · 6b6ba582
      anozdrin/alik@alik. authored
      into  alik.:/mnt/raid/alik/MySQL/devel/5.0-rt
      6b6ba582
  10. 04 Sep, 2006 11 commits
  11. 03 Sep, 2006 1 commit
  12. 02 Sep, 2006 5 commits
  13. 01 Sep, 2006 1 commit