1. 10 Jun, 2011 1 commit
  2. 08 Jun, 2011 1 commit
  3. 06 Jun, 2011 6 commits
  4. 03 Jun, 2011 11 commits
  5. 02 Jun, 2011 1 commit
  6. 01 Jun, 2011 6 commits
    • Bjorn Munch's avatar
      Followup to 12607800, testing it in PB2 didn't work, trying again · f67de030
      Bjorn Munch authored
      Be more explicit about path to (potential) plugin tests dirs
      f67de030
    • Georgi Kodinov's avatar
      BUG 12610784: SET PASSWORD INCORRECTLY KEEP AN OLD EMPTY PASSWORD · d730bc72
      Georgi Kodinov authored
      The check for empty password in the user account was checking the wrong field.
      Fixed to check the proper password hash.
      Test case added.
      Fixed native_password and old_password plugins that suffered from the same
      problems.
      Unambuguated the auth_string ACL_USER member : previously it was used for 
      both password and the authentication string (depending on the plugin). Now
      fixed to contain either the authentication string specified or empty string.
      d730bc72
    • Jon Olav Hauglid's avatar
      Bug#11853126 RE-ENABLE CONCURRENT READS WHILE CREATING · db273b54
      Jon Olav Hauglid authored
                   SECONDARY INDEX IN INNODB
      
      This is a follow-up patch.
      
      This patch moves part of the new test coverage to a test
      file that is only run on debug builds since it used debug-
      only features and therefore broke the test case on
      release builds.
      db273b54
    • Bjorn Munch's avatar
      Bug #12607800 ADD HOOK TO INSTALL TESTS FROM IMPORTED FEATURE TREES · a3880048
      Bjorn Munch authored
      Sets INSTALL_PLUGINTESTDIR if any plugin/*/tests exist
      a3880048
    • Vinay Fisrekar's avatar
      Adding testcases for WL#5743 InnoDB: Lift the limit of index key prefixes · ee358d6d
      Vinay Fisrekar authored
      innodb_prefix_index_liftedlimit.test used for functional testing of increase in prefix index limit
      ee358d6d
    • Jon Olav Hauglid's avatar
      Bug#11853126 RE-ENABLE CONCURRENT READS WHILE CREATING · 5922e3cc
      Jon Olav Hauglid authored
                   SECONDARY INDEX IN INNODB
      
      The patches for Bug#11751388 and Bug#11784056 enabled concurrent
      reads while creating secondary indexes in InnoDB. However, they
      introduced a regression. This regression occured if ALTER TABLE
      failed after the index had been added, for example during the
      lock upgrade needed to update .FRM. If this happened, InnoDB
      and the server got out of sync with regards to which indexes
      actually existed. Therefore the patch for Bug#11815600 again
      disabled concurrent reads.
      
      This patch re-enables concurrent reads. The original regression
      is fixed by splitting the ADD INDEX operation into two parts.
      First the new index is created but not made active. This is
      done while concurrent reads are allowed. The second part of
      the operation makes the index active (or reverts the change).
      This is done after lock upgrade, which prevents the original
      regression.
      
      In order to implement this change, the patch changes the storage
      API for in-place index creation. handler::add_index() is split
      into two functions, handler_add_index() and
      handler::final_add_index(). The former for creating indexes without
      making them visible and the latter for commiting (i.e. making
      visible) new indexes or reverting the changes.
      
      Large parts of this patch were written by Marko Mäkelä.
      
      Test case added to innodb_mysql_lock.test.
      5922e3cc
  7. 31 May, 2011 2 commits
  8. 30 May, 2011 4 commits
    • Davi Arnaut's avatar
      Bug#11766349 - 59443: query_cache_debug.test is occasionally very slow · 8210ef9a
      Davi Arnaut authored
      The test case problem stemmed from the fact that a debug sync
      signal is a global variable that persists until overwritten
      by a new signal. This means that if two different signals
      are raised in sequence, a thread waiting for the first signal
      might miss it if the second signal sets the global variable
      before the thread wakes up.
      
      The solution is to deliver a subsequent signal only after the
      waiting thread has received it.
      
      mysql-test/t/query_cache_debug.test:
        Wait for signal to be delivered.
      8210ef9a
    • Bjorn Munch's avatar
      Bug #12604711 MTR SHOULD READ PLUGIN.DEFS FILES FROM IMPORTED FEATURE TREES · ecfa8f9b
      Bjorn Munch authored
      Added reading from plugin.defs files under plugins/*
      ecfa8f9b
    • Davi Arnaut's avatar
      Merge of mysql-5.1 into mysql-5.5. · 6b13931f
      Davi Arnaut authored
      6b13931f
    • Davi Arnaut's avatar
      Bug#12563279: REGRESSION IN HANDLING PRE-4.1 AUTHENTICATION PACKET · d7a01713
      Davi Arnaut authored
      The problem is that clients implementing the 4.0 version of the
      protocol (that is, mysql-4.0) do not null terminate a string
      at the end of the authentication packet. These clients denote
      the end of the string with the end of the packet.
      
      Although this goes against the documented (see MySQL Internals
      ClientServer Protocol wiki) description of the protocol, these
      old clients still need to be supported.
      
      The solution is to support the documented and actual behavior
      of the clients. If a client is using the pre-4.1 version of
      the protocol, the end of a string in the authentication packet
      can either be denoted with a null character or by the end of
      the packet. This restores backwards compatibility with old
      clients implementing either the documented or actual behavior.
      
      sql/password.c:
        The scrambled message, as provided by the user, might not be
        properly null terminated. If this is the case, uninitialized
        memory past the end of the buffer could theoretically be
        accessed. To ensure that this is never the case, copy the
        scrambled message over to a null terminated auxiliar buffer.
      sql/sql_connect.cc:
        Use different execution paths to read strings depending on the
        protocol being used. If version 4.0 of the protocol is used,
        end of string can be denoted with a NUL character or by the
        end of the packet.
        
        If there are not enough bytes left after the current position
        of the buffer to satisfy the current string, the string is
        considered to be empty. This is required because old clients
        do not send the password string field if the password is empty.
      d7a01713
  9. 27 May, 2011 7 commits
    • Davi Arnaut's avatar
      Null merge of mysql-5.1 into mysql-5.5. · 46ea72ef
      Davi Arnaut authored
      46ea72ef
    • Bjorn Munch's avatar
      Bug #12598603 HAVE COLLECTIONS FILES IN FEATURE TREES AUTO-APPENDED TO COMMON FILES · 298f03ea
      Bjorn Munch authored
      Do this in the common plugin.cmake but only if running in PB2
        (If done in manual builds it would create a bzr diff)
      298f03ea
    • Dmitry Shulga's avatar
    • Davi Arnaut's avatar
      BUG 11763056 - 55721: AIX 5.1.50 build failing, cannot locate bzero · 8be31314
      Davi Arnaut authored
      The problem is that although AIX implements bzero, its prototype
      is not declared by default. Since AC_CHECK_FUNC(bzero) succeeds
      even though a prototype is not declared, this breaks compilation
      in C++ files where a prototype is required.
      
      The solution is to only use bzero if a prototype is also declared.
      
      configure.in:
        Check if bzero is declared. No need to specify the includes,
        unisted.h and strings.h are already part of AC_INCLUDES_DEFAULT.
      8be31314
    • Tatjana Azundris Nuernberg's avatar
      e34e2e02
    • Dmitry Shulga's avatar
      Fixed bug#12546938 (formerly known as 61005) - CREATE IF NOT EXIST EVENT · 71d78450
      Dmitry Shulga authored
      will create multiple running events.
      
      A CREATE IF NOT EXIST on an event that existed and was enabled caused
      multiple instances of the event to run. Disabling the event didn't  help.
      If the event was  dropped, the event stopped running, but when created
      again, multiple instances of the event were still running. The only way
      to get out of this situation was  to restart the server.
      
      The problem was that Event_db_repository::create_event() didn't return
      enough information to discriminate between situation when event didn't
      exist and was created and when event did exist and was not created
      (but a warning was emitted). As result in the latter case event
      was added to in-memory queue of events second time. And this led to
      unwarranted multiple executions of the same event.
      
      The solution is to add out-parameter to Event_db_repository::create_event()
      method which will signal that event was not created because it already
      exists and so it should not be added to the in-memory queue.
      
      
      mysql-test/r/events_bugs.result:
        Added results for test for Bug#12546938.
      mysql-test/t/events_bugs.test:
        Added test for Bug#12546938.
      sql/event_db_repository.cc:
        Event_db_repository::create_event was modified: set newly added out-parameter
        event_already_exists to true value if event wasn't created because event
        already existed and IF NOT EXIST clause was present.
      sql/event_db_repository.h:
        Added out-parameter 'event_already_exists' to create_event() method.
      sql/events.cc:
        Events::create_event was modified: insert new element into
        event queue only if event was actually created.
      71d78450
    • Anitha Gopi's avatar
      Automerge : Updating local tree · 3c87e6f5
      Anitha Gopi authored
      3c87e6f5
  10. 26 May, 2011 1 commit
    • Dmitry Lenev's avatar
      Fix for bug #11762012 - "54553: INNODB ASSERTS IN · 915d24d0
      Dmitry Lenev authored
      HA_INNOBASE::UPDATE_ROW, TEMPORARY TABLE, TABLE LOCK".
      
      Attempt to update an InnoDB temporary table under LOCK TABLES
      led to assertion failure in both debug and production builds
      if this temporary table was explicitly locked for READ. The
      same scenario works fine for MyISAM temporary tables.
      
      The assertion failure was caused by discrepancy between lock
      that was requested on the rows of temporary table at LOCK TABLES
      time and by update operation. Since SQL-layer requested a
      read-lock at LOCK TABLES time InnoDB engine assumed that upcoming
      statements which are going to be executed under LOCK TABLES will
      only read table and therefore should acquire only S-lock.
      An update operation broken this assumption by requesting X-lock.
      
      Possible approaches to fixing this problem are:
      
      1) Skip locking of temporary tables as locking doesn't make any
         sense for connection-local objects.
      2) Prohibit changing of temporary table locked by LOCK TABLES ...
         READ.
      
      Unfortunately both of these approaches have drawbacks which make
      them unviable for stable versions of server.
      
      So this patch takes another approach and changes code in such way
      that LOCK TABLES for a temporary table will always request write
      lock. In 5.5 version of this patch switch from read lock to write
      lock is done on SQL-layer.
      
      mysql-test/suite/innodb/r/innodb_mysql.result:
        Added test for bug #11762012 - "54553: INNODB ASSERTS IN
        HA_INNOBASE::UPDATE_ROW, TEMPORARY TABLE, TABLE LOCK".
      mysql-test/suite/innodb/t/innodb_mysql.test:
        Added test for bug #11762012 - "54553: INNODB ASSERTS IN
        HA_INNOBASE::UPDATE_ROW, TEMPORARY TABLE, TABLE LOCK".
      sql/sql_parse.cc:
        Since a temporary table locked by LOCK TABLES can be updated even
        if it was only locked for read we always request TL_WRITE locks
        for such tables at LOCK TABLES time. This allows to avoid 
        discrepancy between locks acquired at LOCK TABLES time and by
        a statement executed under LOCK TABLES. Such a discrepancy has
        caused problems for InnoDB storage engine.
        
        To support this change a part of code implementing LOCK TABLES 
        has been moved to a helper function.
      915d24d0