1. 09 Jun, 2011 5 commits
    • Dmitry Shulga's avatar
    • Dmitry Shulga's avatar
      Fixed bug#11764334 (formerly bug#57156): ALTER EVENT CHANGES · fa913a0b
      Dmitry Shulga authored
      THE EVENT STATUS.
      
      Any ALTER EVENT statement on a disabled event enabled it back
      (unless this ALTER EVENT statement explicitly disabled the event).
      
      The problem was that during processing of an ALTER EVENT statement
      value of status field was overwritten unconditionally even if new
      value was not specified explicitly. As a consequence this field
      was set to default value for status which corresponds to ENABLE.
      
      The solution is to check if status field was explicitly specified in
      ALTER EVENT statement before assigning new value to status field.
      
      mysql-test/r/events_bugs.result:
        test's result for Bug#11764334 was added.
      mysql-test/t/events_bugs.test:
        new test for Bug#11764334 was added.
      sql/event_db_repository.cc:
        mysql_event_fill_row() was modified: set value for status field
        in events tables only in case if statement CREATE EVENT
        is being processed or if this value was set in ALTER EVENT
        statement.
        Event_db_repository::create_event was modified: removed redundant
        setting of status field after return from call to mysql_event_fill_row().
      sql/event_parse_data.h:
        Event_parse_data structure was modified: added flag
        status_changed that is set to true if status's value
        was changed in ALTER EVENT statement.
      sql/sql_yacc.yy:
        Set flag status_changed if status was set in ALTER EVENT
        statement.
      fa913a0b
    • Dmitry Lenev's avatar
      Fix for bug #11759990 - "52354: 'CREATE TABLE .. LIKE ... ' · 600647c7
      Dmitry Lenev authored
      STATEMENTS FAIL".
      
      Attempt to execute CREATE TABLE LIKE statement on a MyISAM
      table with INDEX or DATA DIRECTORY options specified as a
      source resulted in "MyISAM table '...' is in use..." error.
      According to our documentation such a statement should create
      a copy of source table with DATA/INDEX DIRECTORY options
      omitted.
      
      The problem was that new implementation of CREATE TABLE LIKE
      statement in 5.5 tried to copy value of INDEX and DATA DIRECTORY
      parameters from the source table. Since in description of source
      table this parameters also included name of this table, attempt
      to create target table with these parameter led to file name
      conflict and error.
      
      This fix addresses the problem by preserving documented and
      backward-compatible behavior. I.e. by ensuring that contents
      of DATA/INDEX DIRECTORY clauses for the source table is
      ignored when target table is created.
      
      mysql-test/r/symlink.result:
        Added test for bug #11759990 - "52354: 'CREATE TABLE ..
        LIKE ... ' STATEMENTS FAIL".
      mysql-test/t/symlink.test:
        Added test for bug #11759990 - "52354: 'CREATE TABLE ..
        LIKE ... ' STATEMENTS FAIL".
      sql/sql_table.cc:
        Changed CREATE TABLE LIKE implementation to ignore contents
        of DATA/INDEX DIRECTORY clauses for source table when target
        table is created. This is documented and backward-compatible
        behavior.
      600647c7
    • Marko Mäkelä's avatar
      Merge mysql-5.1 to mysql-5.5. · 34baff77
      Marko Mäkelä authored
      34baff77
    • Marko Mäkelä's avatar
      BLOB instrumentation for Bug#12612184 Race condition in row_upd_clust_rec() · 6348b737
      Marko Mäkelä authored
      If UNIV_DEBUG or UNIV_BLOB_LIGHT_DEBUG is enabled, add
      !rec_offs_any_null_extern() assertions, ensuring that records do not
      contain null pointers to externally stored columns in inappropriate
      places.
      
      btr_cur_optimistic_update(): Assert !rec_offs_any_null_extern().
      Incomplete records must never be updated or deleted. This assertion
      will cover also the pessimistic route.
      
      row_build(): Assert !rec_offs_any_null_extern(). Search tuples must
      never be built from incomplete index entries.
      
      row_rec_to_index_entry(): Assert !rec_offs_any_null_extern() unless
      ROW_COPY_DATA is requested. ROW_COPY_DATA is used for
      multi-versioning, and therefore it might be valid to copy the most
      recent (uncommitted) version while it contains a null pointer to
      off-page columns.
      
      row_vers_build_for_consistent_read(),
      row_vers_build_for_semi_consistent_read(): Assert !rec_offs_any_null_extern()
      on all versions except the most recent one.
      
      trx_undo_prev_version_build(): Assert !rec_offs_any_null_extern() on
      the previous version.
      
      rb:682 approved by Sunny Bains
      6348b737
  2. 08 Jun, 2011 1 commit
  3. 07 Jun, 2011 3 commits
    • Ramil Kalimullin's avatar
      Auto-merge from mysql-5.1 · ab3cae3d
      Ramil Kalimullin authored
      ab3cae3d
    • Ramil Kalimullin's avatar
      Bug#11764487: myisam corruption with insert ignore and invalid spatial data · 768b9a0e
      Ramil Kalimullin authored
      Problem: in case of wrong data insert into indexed GEOMETRY fields 
      (e.g. NULL value for a not NULL field) MyISAM reported 
      "ERROR 126 (HY000): Incorrect key file for table; try to repair it"
      due to misuse of the key deletion function.
      
      Fix: always use R-tree key functions for R-tree based indexes
      and B-tree key functions for B-tree based indexes.
      
      
      mysql-test/r/gis-rtree.result:
        Bug#11764487: myisam corruption with insert ignore and invalid spatial data
          - test result.
      mysql-test/t/gis-rtree.test:
        Bug#11764487: myisam corruption with insert ignore and invalid spatial data
          - test case.
      storage/myisam/mi_update.c:
        Bug#11764487: myisam corruption with insert ignore and invalid spatial data
          - handling update errors check for HA_ERR_NULL_IN_SPATIAL as well to be 
        consistent with mi_write();
          - always use keyinfo->ck_delete()/ck_insert() instead of _mi_ck_delete()/_mi_ck_write()
        to handle index properly, as it may be of B-tree or R-tree type.
      storage/myisam/mi_write.c:
        Bug#11764487: myisam corruption with insert ignore and invalid spatial data
          - always use keyinfo->ck_delete() instead of _mi_ck_delete() to handle
        index properly, as it may be of B-tree or R-tree type.
      768b9a0e
    • Alexander Nozdrin's avatar
      e3a43936
  4. 06 Jun, 2011 5 commits
  5. 03 Jun, 2011 11 commits
  6. 02 Jun, 2011 1 commit
  7. 01 Jun, 2011 5 commits
    • Bjorn Munch's avatar
      Followup to 12607800, testing it in PB2 didn't work, trying again · aca402b6
      Bjorn Munch authored
      Be more explicit about path to (potential) plugin tests dirs
      aca402b6
    • Jon Olav Hauglid's avatar
      Bug#11853126 RE-ENABLE CONCURRENT READS WHILE CREATING · edcd89ee
      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.
      edcd89ee
    • Bjorn Munch's avatar
      Bug #12607800 ADD HOOK TO INSTALL TESTS FROM IMPORTED FEATURE TREES · fd717fb5
      Bjorn Munch authored
      Sets INSTALL_PLUGINTESTDIR if any plugin/*/tests exist
      fd717fb5
    • Vinay Fisrekar's avatar
      Adding testcases for WL#5743 InnoDB: Lift the limit of index key prefixes · 46c2089d
      Vinay Fisrekar authored
      innodb_prefix_index_liftedlimit.test used for functional testing of increase in prefix index limit
      46c2089d
    • Jon Olav Hauglid's avatar
      Bug#11853126 RE-ENABLE CONCURRENT READS WHILE CREATING · 9b076952
      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.
      9b076952
  8. 31 May, 2011 2 commits
  9. 30 May, 2011 4 commits
    • Davi Arnaut's avatar
      Bug#11766349 - 59443: query_cache_debug.test is occasionally very slow · c7d2ec7d
      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.
      c7d2ec7d
    • Bjorn Munch's avatar
      Bug #12604711 MTR SHOULD READ PLUGIN.DEFS FILES FROM IMPORTED FEATURE TREES · ec0b030f
      Bjorn Munch authored
      Added reading from plugin.defs files under plugins/*
      ec0b030f
    • Davi Arnaut's avatar
      Merge of mysql-5.1 into mysql-5.5. · 9f6ec599
      Davi Arnaut authored
      9f6ec599
    • Davi Arnaut's avatar
      Bug#12563279: REGRESSION IN HANDLING PRE-4.1 AUTHENTICATION PACKET · 9b68760f
      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.
      9b68760f
  10. 27 May, 2011 3 commits