1. 19 Oct, 2009 1 commit
    • Kristofer Pettersson's avatar
      Bug#47627 SET @@{global.session}.local_variable in stored routine causes crash · 4d937b6a
      Kristofer Pettersson authored
      Adding @@session and @@global prefixes to a
      declared variable in a stored procedure the server
      would lead to a crash.
      
      The reason was that during the parsing of the
      syntactic rule 'option_value' an uninitialized
      set_var object was pushed to the parameter stack
      of the SET statement. The parent rule
      'option_type_value'  interpreted the existence of
      variables on the parameter stack as an assignment
      and wrapped it in a sp_instr_set object.
      
      As the procedure later was executed an attempt
      was made to run the method 'check()' on an
      uninitialized member object (NULL value) belonging
      to the previously created but uninitialized object.
      4d937b6a
  2. 12 Oct, 2009 3 commits
  3. 09 Oct, 2009 9 commits
  4. 08 Oct, 2009 12 commits
  5. 07 Oct, 2009 2 commits
  6. 06 Oct, 2009 10 commits
    • Magnus Blåudd's avatar
      Bug#47857 strip_sp function in mysys/mf_strip.c never used and cause name clash · b64dbeed
      Magnus Blåudd authored
       - Remove mf_strip.c and the declaration of 'strip_sp'
      b64dbeed
    • Alfranio Correia's avatar
      2a243fa2
    • Kristofer Pettersson's avatar
      Automerge · 14f76673
      Kristofer Pettersson authored
      14f76673
    • Kristofer Pettersson's avatar
      automerge · 618d7980
      Kristofer Pettersson authored
      618d7980
    • Kristofer Pettersson's avatar
      66e77c86
    • Kristofer Pettersson's avatar
      Automerg · 499121a0
      Kristofer Pettersson authored
      499121a0
    • Kristofer Pettersson's avatar
      Bug#47768 pthread_cond_timedwait() is broken on windows · dfed28e7
      Kristofer Pettersson authored
      The pthread_cond_wait implementations for windows might
      dead lock in some rare circumstances.
      
      1) One thread (I) enter a timed wait and at a point in
         time ends up after mutex unlock and before
         WaitForMultipleObjects(...)
      2) Another thread (II) enters pthread_cond_broadcast.
         Grabs the mutex and discovers one waiter. It set
         the broadcast event and closes the broadcast gate
         then unlocks the mutex.
      3) A third thread (III) issues a pthread_cond_signal.
         It grabs the mutex, discovers one waiter, sets the
         signal event then unlock the mutex.
      4) The first threads (I) enters WaitForMultipleObjects
         and finds out that the signal object is in a
         signalled state and exits the wait.
      5) Thread (I) grabs the mutex and checks result status.
         The number of waiters is decreased and becomes equal
         to 0. The event returned was a signal event so the
         broadcast gate isn't opened. The mutex is released.
      6) Thread (II) issues a new broadcast. The mutex is
         acquired but the number of waiters are 0 hence
         the broadcast gate remains closed.
      7) Thread (I) enters the wait again but is blocked by
         the broadcast gate.
      
            This fix resolves the above issue by always resetting
            broadcast gate when there are no more waiters in th queue.
      dfed28e7
    • Georgi Kodinov's avatar
      merge mysql-5.1-pe · cfd737a4
      Georgi Kodinov authored
      cfd737a4
    • Alfranio Correia's avatar
      BUG#47678 Changes to n-tables that happen early in a trans. are only flushed upon commit · b31e0c9a
      Alfranio Correia authored
        Let
          - T be a transactional table and N non-transactional table.
          - B be begin, C commit and R rollback.
          - N be a statement that accesses and changes only N-tables.
          - T be a statement that accesses and changes only T-tables.
      
      In RBR, changes to N-tables that happen early in a transaction are not immediately flushed
      upon committing a statement. This behavior may, however, break consistency in the presence
      of concurrency since changes done to N-tables become immediately visible to other
      connections. To fix this problem, we do the following:
      
        . B N N T C would log - B N C B N C B T C.
        . B N N T R would log - B N C B N C B T R.
      
      Note that we are not preserving history from the master as we are introducing a commit that
      never happened. However, this seems to be more acceptable than the possibility of breaking
      consistency in the presence of concurrency.
      b31e0c9a
    • Alfranio Correia's avatar
      BUG#47287 RBR: replication diff on basic case with txn- and non-txn tables in a statement · 678eb3d6
      Alfranio Correia authored
      Let
        - T be a transactional table and N non-transactional table.
        - B be begin, C commit and R rollback.
        - M be a mixed statement, i.e. a statement that updates both T and N.
        - M* be a mixed statement that fails while updating either T or N.
      
      This patch restore the behavior presented in 5.1.37 for rows either produced in
      the RBR or MIXED modes, when a M* statement that happened early in a transaction
      had their changes written to the binary log outside the boundaries of the
      transaction and wrapped in a BEGIN/ROLLBACK. This was done to keep the slave
      consistent with with the master as the rollback would keep the changes on N and
      undo them on T. In particular, we do what follows:
      
        . B M* T C would log - B M* R B T C.
      
      Note that, we are not preserving history from the master as we are introducing a
      rollback that never happened. However, this seems to be more acceptable than
      making the slave diverge. We do not fix the following case:
      
        . B T M* C would log B T M* C.
      
      The slave will diverge as the changes on T tables that originated from the M
      statement are rolled back on the master but not on the slave. Unfortunately, we
      cannot simply rollback the transaction as this would undo any uncommitted
      changes on T tables.
      
      SBR is not considered in this patch because a failing statement is written to
      the binary along with the error code and a slave executes and then rolls back
      the statement when it has an associated error code, thus undoing the effects
      on T. In RBR and MBR, a full-fledged fix will be pushed after the WL 2687.
      678eb3d6
  7. 05 Oct, 2009 3 commits