1. 28 Jul, 2010 1 commit
    • Konstantin Osipov's avatar
      Fix a failing assert when running funcs_1.innodb_trig_03 test. · 0b217d90
      Konstantin Osipov authored
      The failure was introduced by a precursor patch for the
      fix for Bug#52044.
      
      When opening tables for GRANT statement
      to check that subject columns exist,
      mysql_table_grant() would try to lock the
      tables, and thus start a transaction.
      This was unnecessary and lead to an assert.
      0b217d90
  2. 27 Jul, 2010 4 commits
    • Konstantin Osipov's avatar
      2abe7b9d
    • Davi Arnaut's avatar
      Bug#52261: 64 bit atomic operations do not work on Solaris i386 .. · c6a34a99
      Davi Arnaut authored
      Workaround a interface problem with the atomic macros that was
      causing warnings. The correct type is retrieved using typeof if
      compiling with GCC.
      c6a34a99
    • Konstantin Osipov's avatar
      Implement WL#5502 Remove dead 5.0 class Sensitive_cursor. · 6d059673
      Konstantin Osipov authored
      Remove dead and unused code.
      Update to reflect the code review requests.
      6d059673
    • Konstantin Osipov's avatar
      A pre-requisite patch for the fix for Bug#52044. · ec2c3bf2
      Konstantin Osipov authored
      This patch also fixes Bug#55452 "SET PASSWORD is
      replicated twice in RBR mode".
      
      The goal of this patch is to remove the release of 
      metadata locks from close_thread_tables().
      This is necessary to not mistakenly release
      the locks in the course of a multi-step
      operation that involves multiple close_thread_tables()
      or close_tables_for_reopen().
      
      On the same token, move statement commit outside 
      close_thread_tables().
      
      Other cleanups:
      Cleanup COM_FIELD_LIST.
      Don't call close_thread_tables() in COM_SHUTDOWN -- there
      are no open tables there that can be closed (we leave
      the locked tables mode in THD destructor, and this
      close_thread_tables() won't leave it anyway).
      
      Make open_and_lock_tables() and open_and_lock_tables_derived()
      call close_thread_tables() upon failure.
      Remove the calls to close_thread_tables() that are now
      unnecessary.
      
      Simplify the back off condition in Open_table_context.
      
      Streamline metadata lock handling in LOCK TABLES 
      implementation.
      
      Add asserts to ensure correct life cycle of 
      statement transaction in a session.
      
      Remove a piece of dead code that has also become redundant
      after the fix for Bug 37521.
      ec2c3bf2
  3. 26 Jul, 2010 5 commits
  4. 25 Jul, 2010 1 commit
    • Vladislav Vaintroub's avatar
      Cleanup after bild team push. · 99a26e0f
      Vladislav Vaintroub authored
      * Fixed obvious errors (HAVE_BROKEN_PREAD is not true for on any
      of systems we use, definitely not on HPUX)
      
      * Remove other junk flags for OSX and HPUX
      
      * Avoid checking type sizes in universal builds on OSX, again 
      (CMake2.8.0 fails is different architectures return different results)
      
      * Do not compile template instantiation stuff unless 
      EXPLICIT_TEMPLATE_INSTANTIATION is used.
      
      * Some cleanup (make gen_lex_hash simpler, avoid dependencies)
      
      * Exclude some unused files from compilation (strtol.c etc)
      99a26e0f
  5. 24 Jul, 2010 4 commits
  6. 23 Jul, 2010 11 commits
  7. 22 Jul, 2010 3 commits
    • Davi Arnaut's avatar
    • Jon Olav Hauglid's avatar
      Bug #54905 Connection with WRITE lock cannot ALTER table due to · e814e9ac
      Jon Olav Hauglid authored
                 concurrent SHOW CREATE
      
      The problem was that a SHOW CREATE TABLE statement issued inside
      a transaction did not release its metadata locks at the end of the
      statement execution. This happened even if SHOW CREATE TABLE is an
      information statement. 
      
      The consequence was that SHOW CREATE TABLE was able to block other
      connections from accessing the table (e.g. using ALTER TABLE).
      
      This patch fixes the problem by explicitly releasing any metadata
      locks taken by SHOW CREATE TABLE after the statement completes.
      
      Test case added to show_check.test.
      e814e9ac
    • Jon Olav Hauglid's avatar
      Bug #55223 assert in Protocol::end_statement during CREATE DATABASE · 13109514
      Jon Olav Hauglid authored
      The problem was that a statement could cause an assert if it was aborted by
      KILL QUERY while it waited on a metadata lock. This assert checks that a
      statement either sends OK or an error to the client. If the bug was triggered
      on release builds, it caused OK to be sent to the client instead of
      ER_QUERY_INTERRUPTED.
      
      The root cause of the problem was that there are two separate ways to tell if a
      statement is killed: thd->killed and mysys_var->abort. KILL QUERY causes both
      to be set, thd->killed before mysys_var->abort. Also, both values are reset
      at the end of statement execution. This means that it is possible for
      KILL QUERY to first set thd->killed, then have the killed statement reset
      both thd->killed and mysys_var->abort and finally have KILL QUERY set
      mysys_var->abort. This means that the connection with the killed statement
      will start executing the next statement with the two values out of sync - i.e.
      thd->killed not set but mysys_var->abort set.
      
      Since mysys_var->abort is used to check if a wait for a metadata lock should
      be aborted, the next statement would immediately abort any such waiting.
      When waiting is aborted, no OK message is sent and thd->killed is checked to
      see if ER_QUERY_INTERRUPTED should be sent to the client. But since
      the->killed had been reset, neither OK nor an error message was sent to the
      client. This then triggered the assert.
      
      This patch fixes the problem by changing the metadata lock waiting code to
      check thd->killed.
      
      No test case added as reproducing the assert is dependent on very exact timing
      of two (or more) threads. The patch has been checked using RQG and the grammar
      posted on the bug report.
      13109514
  8. 20 Jul, 2010 2 commits
  9. 23 Jul, 2010 3 commits
    • Davi Arnaut's avatar
      Bug#22320: my_atomic-t unit test fails · 3a22d332
      Davi Arnaut authored
      Bug#52261: 64 bit atomic operations do not work on Solaris i386
                 gcc in debug compilation
      
      One of the various problems was that the source operand to
      CMPXCHG8b was marked as a input/output operand, causing GCC
      to use the EBX register as the destination register for the
      CMPXCHG8b instruction. This could lead to crashes as the EBX
      register is also implicitly used by the instruction, causing
      the value to be potentially garbaged and a protection fault
      once the value is used to access a position in memory.
      
      Another problem was the lack of proper clobbers for the atomic
      operations and, also, a discrepancy between the implementations
      for the Compare and Set operation. The specific problems are
      described and fixed by Kristian Nielsen patches:
      
      Patch: 1
      
      Fix bugs in my_atomic_cas*(val,cmp,new) that *cmp is accessed
      after CAS succeds.
      
      In the gcc builtin implementation, problem was that *cmp was
      read again after atomic CAS to check if old *val == *cmp;
      this fails if CAS is successful and another thread modifies
      *cmp in-between.
      
      In the x86-gcc implementation, problem was that *cmp was set
      also in the case of successful CAS; this means there is a
      window where it can clobber a value written by another thread
      after successful CAS.
      
      Patch 2:
      
      Add a GCC asm "memory" clobber to primitives that imply a
      memory barrier.
      
      This signifies to GCC that any potentially aliased memory
      must be flushed before the operation, and re-read after the
      operation, so that read or modification in other threads of
      such memory values will work as intended.
      
      In effect, it makes these primitives work as memory barriers
      for the compiler as well as the CPU. This is better and more
      correct than adding "volatile" to variables.
      3a22d332
    • Alexander Nozdrin's avatar
      Auto-merge (empty) from mysql-trunk. · 75437057
      Alexander Nozdrin authored
      75437057
    • Alexander Nozdrin's avatar
      Auto-merge from mysql-trunk-bugfixing. · 76f80ae9
      Alexander Nozdrin authored
      76f80ae9
  10. 20 Jul, 2010 2 commits
  11. 19 Jul, 2010 4 commits
    • Davi Arnaut's avatar
      Merge into mysql-trunk-merge.. · ce2403e6
      Davi Arnaut authored
      ce2403e6
    • Evgeny Potemkin's avatar
      Bug#49771: Incorrect MIN/MAX for date/time values. · 589027b2
      Evgeny Potemkin authored
      This bug is a design flaw of the fix for the bug#33546. It assumed that an
      item can be used only in one comparison context, but actually it isn't the
      case. Item_cache_datetime is used to store result for MIX/MAX aggregate
      functions. Because Arg_comparator always compares datetime values as INTs when
      possible the Item_cache_datetime most time caches only INT value. But
      since all datetime values has STRING result type MIN/MAX functions are asked
      for a STRING value when the result is being sent to a client. The
      Item_cache_datetime was designed to avoid conversions and get INT/STRING
      values from an underlying item, but at the moment the values is asked
      underlying item doesn't hold it anymore thus wrong result is returned.
      Beside that MIN/MAX aggregate functions was wrongly initializing cached result
      and this led to a wrong result.
      
      The Item::has_compatible_context helper function is added. It checks whether
      this and given items has the same comparison context or can be compared as
      DATETIME values by Arg_comparator. The equality propagation optimization is
      adjusted to take into account that items which being compared as DATETIME
      can have different comparison contexts.
      The Item_cache_datetime now converts cached INT value to a correct STRING
      DATETIME value by means of number_to_datetime & my_TIME_to_str functions.
      The Arg_comparator::set_cmp_context_for_datetime helper function is added. 
      It sets comparison context of items being compared as DATETIMEs to INT if
      items will be compared as longlong.
      The Item_sum_hybrid::setup function now correctly initializes its result
      value.
      In order to avoid unnecessary conversions Item_sum_hybrid now states that it
      can provide correct longlong value if the item being aggregated can do it
      too.
      589027b2
    • Jonathan Perkin's avatar
      bug#55250: 5.5.5-m3 incorrectly compiled with exceptions on Solaris/x86 · 40856e83
      Jonathan Perkin authored
      Put '-features=no%except' back into Solaris/x86 CXXFLAGS.
      40856e83
    • Alexander Nozdrin's avatar
      Manual merge from mysql-trunk. · 9503a8e2
      Alexander Nozdrin authored
      Conflicts:
        - scripts/CMakeLists.txt
      9503a8e2