1. 31 Jul, 2007 1 commit
    • unknown's avatar
      ha_innodb.cc: · a0af9b7e
      unknown authored
        Warning fixed.
      
      
      sql/ha_innodb.cc:
        Warning fixed.
      a0af9b7e
  2. 30 Jul, 2007 3 commits
    • unknown's avatar
      Merge epotemkin@bk-internal.mysql.com:/home/bk/mysql-5.0-opt · 3887705e
      unknown authored
      into  moonbone.local:/mnt/gentoo64/work/24989-bug-5.0-opt-mysql
      
      
      sql/ha_innodb.cc:
        Auto merged
      sql/handler.cc:
        Auto merged
      sql/sql_class.cc:
        Auto merged
      sql/sql_class.h:
        Auto merged
      3887705e
    • unknown's avatar
      Bug#24989: The DEADLOCK error is improperly handled by InnoDB. · 9246c372
      unknown authored
      When innodb detects a deadlock it calls ha_rollback_trans() to rollback the 
      main transaction. But such action isn't allowed from inside of triggers and
      functions. When it happen the 'Explicit or implicit commit' error is thrown
      even if there is no commit/rollback statements in the trigger/function. This
      leads to the user confusion.
      
      Now the convert_error_code_to_mysql() function doesn't call the 
      ha_rollback_trans() function directly but rather calls the
      mark_transaction_to_rollback function and returns an error.
      The sp_rcontext::find_handler() now doesn't allow errors to be caught by the
      trigger/function error handlers when the thd->is_fatal_sub_stmt_error flag
      is set. Procedures are still allowed to catch such errors.
      The sp_rcontext::find_handler function now accepts a THD handle as a parameter.
      The transaction_rollback_request and the is_fatal_sub_stmt_error flags are 
      added to the THD class. The are initialized by the THD class constructor.
      Now the ha_autocommit_or_rollback function rolls back main transaction
      when not in a sub statement and the thd->transaction_rollback_request
      is set.
      The THD::restore_sub_statement_state function now resets the 
      thd->is_fatal_sub_stmt_error flag on exit from a sub-statement.
      
      
      sql/ha_innodb.cc:
        Bug#24989: The DEADLOCK error is improperly handled by InnoDB.
        Now the convert_error_code_to_mysql() function doesn't call the
        ha_rollback_trans() function directly but rather calls the
        mark_transaction_to_rollback function and returns an error.
      sql/handler.cc:
        Bug#24989: The DEADLOCK error is improperly handled by InnoDB.
        Now the ha_autocommit_or_rollback function rolls back main transaction
        when not in a sub statement and the thd->transaction_rollback_request
        is set.
      mysql-test/r/innodb-big.result:
        Added a test case for the bug#24989: The DEADLOCK error is improperly handled by
        InnoDB.
      mysql-test/t/innodb-big.test:
        Added a test case for the bug#24989: The DEADLOCK error is improperly handled by
        InnoDB.
      sql/sql_class.h:
        Bug#24989: The DEADLOCK error is improperly handled by InnoDB.
        The transaction_rollback_request and the is_fatal_sub_stmt_error flags are 
        added to the THD class.
      sql/sql_class.cc:
        Bug#24989: The DEADLOCK error is improperly handled by InnoDB.
        Initialization of the transaction_rollback_request and the
        is_fatal_sub_stmt_error flags are added to the THD class constructor.
        The mark_transaction_to_rollback function is added.
        The THD::restore_sub_statement_state function now resets the
        thd->is_fatal_sub_stmt_error flag on exit from a sub-statement.
      sql/sp_rcontext.h:
        Bug#24989: The DEADLOCK error is improperly handled by InnoDB.
        The sp_rcontext::find_handler function now accepts a THD handle as a parameter.
        The in_sub_stmt flag is added to the sp_rcontext class.
      sql/sp_rcontext.cc:
        Bug#24989: The DEADLOCK error is improperly handled by InnoDB.
        The sp_rcontext::find_handler() now doesn't allow errors to be caught by the
        trigger/function error handlers when the thd->is_fatal_sub_stmt_error flag
        is set. Instead it tries to find a most inner procedure that isn't called
        directly or indirectly from any function/trigger.
        Procedures are still allowed to catch such errors.
        The sp_rcontext::find_handler function now accepts a THD handle as a parameter.
      9246c372
    • unknown's avatar
      Moved the DBUG_ASSERT from bug 28983 to · b9097abf
      unknown authored
      a place where it would not obstruct
      correct multithreading.
      
      
      b9097abf
  3. 28 Jul, 2007 8 commits
    • unknown's avatar
      Merge epotemkin@bk-internal.mysql.com:/home/bk/mysql-5.0-opt · d86f0a13
      unknown authored
      into  moonbone.local:/mnt/gentoo64/work/29856-bug-5.0-opt-mysql
      
      
      sql/sp_head.cc:
        Auto merged
      mysql-test/r/query_cache.result:
        SCCS merged
      mysql-test/t/query_cache.test:
        SCCS merged
      d86f0a13
    • unknown's avatar
      Merge gshchepa@bk-internal.mysql.com:/home/bk/mysql-5.0-opt · ba9e6a56
      unknown authored
      into  gleb.loc:/home/uchum/work/bk/5.0-opt
      
      
      ba9e6a56
    • unknown's avatar
      Merge gleb.loc:/home/uchum/work/bk/5.0-opt-29834 · 3c171615
      unknown authored
      into  gleb.loc:/home/uchum/work/bk/5.0-opt
      
      
      sql/sql_base.cc:
        Auto merged
      mysql-test/r/sp.result:
        Merge with local tree.
      mysql-test/t/sp.test:
        Merge with local tree.
      3c171615
    • unknown's avatar
      Fixed bug #29834. · 90c5621d
      unknown authored
      Using view columns by their names during an execution of
      a prepared SELECT statement or a SELECT statement inside
      a SP caused a memory leak.
      
      
      sql/sql_base.cc:
        Fixed bug #29834.
        The find_field_in_view function has been modified to
        use the execution memory root for the Item_direct_view_ref
        objects allocation at non-first executions of
        a PS/SP instead of the statement memory.
      mysql-test/t/sp.test:
        Updated test case for bug #29834.
      mysql-test/r/sp.result:
        Updated test case for bug #29834.
      90c5621d
    • unknown's avatar
      Merge epotemkin@bk-internal.mysql.com:/home/bk/mysql-5.0-opt · da265288
      unknown authored
      into  moonbone.local:/mnt/gentoo64/work/30020-bug-5.0-opt-mysql
      
      
      da265288
    • unknown's avatar
      Merge gleb.loc:/home/uchum/work/bk/5.0 · bb2d58f5
      unknown authored
      into  gleb.loc:/home/uchum/work/bk/5.0-opt
      
      
      bb2d58f5
    • unknown's avatar
      Bug#30020: Insufficient check led to a wrong info provided by the · aa4a3c9a
      unknown authored
      information schema table.
      
      The get_schema_views_record() function fills records in the view table of
      the informations schema with data about given views. Among other info
      the is_updatable flag is set. But the check whether the view is updatable or
      not wasn't covering all cases thus sometimes providing wrong info.
      This might led to a user confusion.
      
      Now the get_schema_views_record function additionally calls to the 
      view->can_be_merge() function to find out whether the view can be updated or
      not.
      
      
      mysql-test/t/view.test:
        Added a test case for the bug#30020: Insufficient check led to a wrong info
        provided by the information schema table.
      mysql-test/r/view.result:
        Added a test case for the bug#30020: Insufficient check led to a wrong info
        provided by the information schema table.
      sql/sql_show.cc:
        Bug#30020: Insufficient check led to a wrong info provided by the
        information schema table.
        Now the get_schema_views_record function additionally calls to the 
        view->can_be_merge() function to find out whether the view can be updated or
        not.
      aa4a3c9a
    • unknown's avatar
      Bug#29856: Insufficient buffer space led to a server crash. · 40d596c2
      unknown authored
      The subst_spvars function is used to create query string with SP variables 
      substituted with their values. This string is used later for the binary log
      and for the query cache. The problem is that the
      query_cache_send_result_to_client function requires some additional space
      after the query to store database name and query cache flags. This 
      space wasn't reserved by the subst_spvars function which led to a memory
      corruption and crash.
      
      Now the subst_spvars function reserves additional space for the query cache.
      
      
      mysql-test/t/query_cache.test:
        Added a test case for the bug#29856: Insufficient buffer space led to a server crash.
      mysql-test/r/query_cache.result:
        Added a test case for the bug#29856: Insufficient buffer space led to a server crash.
      sql/sp_head.cc:
        Bug#29856: Insufficient buffer space led to a server crash.
        Now the subst_spvars function reserves additional space for the query cache.
      40d596c2
  4. 27 Jul, 2007 4 commits
    • unknown's avatar
      Merge bk@192.168.21.1:mysql-5.0-opt · 0ce78553
      unknown authored
      into  mysql.com:/home/hf/work/29878/my50-29878
      
      
      0ce78553
    • unknown's avatar
      Bug #29878 Garbage data generation when executing SESSION_USER() on a slave. · d27bf14e
      unknown authored
      Item_func_user doesn't calculate anything in it's val_str() method,
      just returns saved str_value.
      Though Item::save_in_field method can destroy str_value, relying on
      val_str() return. As a result we get the garbage stored in field.
      
      We cannot use Item::save_in_field implementation for Item_func_user,
      reimplement it in simpler way.
      
      
      mysql-test/r/rpl_session_var.result:
        Bug #29878 Garbage data generation when executing SESSION_USER() on a slave.
        
        test result
      mysql-test/t/rpl_session_var.test:
        Bug #29878 Garbage data generation when executing SESSION_USER() on a slave.
        
        test case
      sql/item.cc:
        Bug #29878 Garbage data generation when executing SESSION_USER() on a slave.
        
        duplicating code moved to Item::save_str_in_field
      sql/item.h:
        Bug #29878 Garbage data generation when executing SESSION_USER() on a slave.
        
        duplicating code moved to Item::save_str_in_field
      sql/item_strfunc.h:
        Bug #29878 Garbage data generation when executing SESSION_USER() on a slave.
        
        Item_func_user::save_in_field implemented as simple storing str_value
      d27bf14e
    • unknown's avatar
      Merge svojtovich@bk-internal.mysql.com:/home/bk/mysql-5.0-engines · 766725c5
      unknown authored
      into  mysql.com:/home/svoj/devel/mysql/BUG29957/mysql-5.0-engines
      
      
      766725c5
    • unknown's avatar
      BUG#29957 - alter_table.test fails · e92ce5d5
      unknown authored
      INSERT/DELETE/UPDATE followed by ALTER TABLE within LOCK TABLES
      may cause table corruption on Windows.
      
      That happens because ALTER TABLE writes outdated shared state
      info into index file.
      
      Fixed by removing obsolete workaround.
      
      Affects MyISAM tables on Windows only.
      
      
      myisam/mi_extra.c:
        On windows when mi_extra(HA_EXTRA_PREPARE_FOR_DELETE) is called,
        we release external lock and close index file. If we're in LOCK
        TABLES, MyISAM state info doesn't get updated until UNLOCK TABLES.
        
        That means when we release external lock and we're in LOCK TABLES,
        we may write outdated state info.
        
        As SQL layer closes all table instances, we do not need this
        workaround anymore.
      mysql-test/r/alter_table.result:
        A test case for BUG#29957.
      mysql-test/t/alter_table.test:
        A test case for BUG#29957.
      e92ce5d5
  5. 26 Jul, 2007 7 commits
    • unknown's avatar
      Merge spetrunia@bk-internal.mysql.com:/home/bk/mysql-5.0-opt · 1a6ced2c
      unknown authored
      into  mysql.com:/home/psergey/mysql-5.0-bdb-fix
      
      
      1a6ced2c
    • unknown's avatar
      BUG#28591: make the fix work for BDB tables too: · 9206f684
      unknown authored
       - make ha_berkeley::cmp_ref() take into account that auto-generated PKs 
         are stored in LSB-first order. 
       - Remove the temporary code that made the bugfix work for innodb only 
      
      
      mysql-test/r/bdb.result:
        Adjust test-results.
      sql/ha_berkeley.cc:
        BUG#28591: make the fix work for BDB tables too:
         - make ha_berkeley::cmp_ref() take into account that auto-generated PKs 
           are stored in LSB-first order.
      sql/sql_select.cc:
        BUG#28591: Remove "innodb only" clause as the fix now works for BDB too
      sql/table.cc:
        BUG#28591: Remove "innodb only" clause as the fix now works for BDB too
      9206f684
    • unknown's avatar
      Merge xiphis.org:/anubis/antony/work/mysql-5.0-engines · b7eca8bc
      unknown authored
      into  xiphis.org:/anubis/antony/work/mysql-5.0-engines.merge
      
      
      b7eca8bc
    • unknown's avatar
    • unknown's avatar
      Merge gkodinov@bk-internal.mysql.com:/home/bk/mysql-5.0-opt · 935ce762
      unknown authored
      into  magare.gmz:/home/kgeorge/mysql/autopush/B29571-5.0-opt
      
      
      sql/sql_insert.cc:
        Auto merged
      935ce762
    • unknown's avatar
      Bug #29571: INSERT DELAYED IGNORE written to binary log on · 5babac53
      unknown authored
       the master but on the slave
      
      MySQL can decide to "downgrade" a INSERT DELAYED statement
      to normal insert in certain situations.
      One such situation is when the slave is replaying a 
      replication feed.
      However INSERT DELAYED is logged even if there're no updates
      whereas the NORMAL INSERT is not logged in such cases.
      
      Fixed by always logging a "downgraded" INSERT DELAYED: even 
      if there were no updates.
      
      
      mysql-test/r/rpl_insert_delayed.result:
        Bug #29571: test case
      mysql-test/t/rpl_insert_delayed.test:
        Bug #29571: test case
      sql/sql_insert.cc:
        Bug #29571: log INSERT DELAYED even if it was 
        "downgraded" to INSERT (and there were no updates)
      5babac53
    • unknown's avatar
      fix pushbuild failures · 85af6ba9
      unknown authored
      
      sql/ha_federated.cc:
        remote_error_number is set to -1 when an error was already reported
        with my_error(). ER(-1) will also cause a crash on 64bit arch and only
        worked on 32bit arch by luck
      85af6ba9
  6. 25 Jul, 2007 3 commits
    • unknown's avatar
      Merge gleb.loc:/home/uchum/work/bk/5.0 · 2df3b7b0
      unknown authored
      into  gleb.loc:/home/uchum/work/bk/5.0-opt
      
      
      mysql-test/t/create.test:
        Auto merged
      sql/field.cc:
        Auto merged
      sql/sql_base.cc:
        Auto merged
      sql/table.cc:
        Auto merged
      mysql-test/r/create.result:
        Merge with 5.0 (main).
      2df3b7b0
    • unknown's avatar
      Bug#25679 · b42247bc
      unknown authored
        "Federated Denial of Service"
        Federated storage engine used to attempt to open connections within
        the ::create() and ::open() methods which are invoked while LOCK_open
        mutex is being held by mysqld. As a result, no other client sessions
        can open tables while Federated is attempting to open a connection.
        Long DNS lookup times would stall mysqld's operation and a rogue
        connection string which connects to a remote server which simply
        stalls during handshake can stall mysqld for a much longer period of
        time.
        This patch moves the opening of the connection much later, when the
        federated actually issues queries, by which time the LOCK_open mutex is
        no longer being held.
      
      
      mysql-test/r/federated.result:
        change of test/results due to patch for bug25679
      mysql-test/t/federated.test:
        change of test/results due to patch for bug25679
      sql/ha_federated.cc:
        bug25679
          remove function check_foreign_fata_source()
          ha_federated::open() no longer opens the federated connection.
          ha_federated::create() no longer opens and tests connection.
          ha_federated::real_connect() opens connection and tests presence of table.
          ha_federated::real_query() sends query, calling real_connect() if neccessary.
      sql/ha_federated.h:
        bug25679
          new methods real_query() and real_connect()
      b42247bc
    • unknown's avatar
      Merge gleb.loc:/home/uchum/work/bk/4.1-opt · 0784d924
      unknown authored
      into  gleb.loc:/home/uchum/work/bk/5.0-opt
      
      
      0784d924
  7. 24 Jul, 2007 6 commits
    • unknown's avatar
      Merge bk-internal.mysql.com:/home/bk/mysql-5.0 · 607ab14c
      unknown authored
      into  bodhi.(none):/opt/local/work/mysql-5.0-runtime
      
      
      607ab14c
    • unknown's avatar
      fix compile on Windows for bug25714.c · 5415dcc3
      unknown authored
      ---
      fix compile on Windows for bug25714.c
      
      
      tests/bug25714.c:
        fix compile on Windows
      5415dcc3
    • unknown's avatar
      build bug25714 test app on Windows · 4ab0c0cf
      unknown authored
      4ab0c0cf
    • unknown's avatar
      Bug#15130: CREATE .. SELECT was denied to use advantages of the SQL_BIG_RESULT. · c4d53e31
      unknown authored
      When the SQL_BIG_RESULT flag is specified SELECT should store items from the
      select list in the filesort data and use them when sending to a client.
      The get_addon_fields function is responsible for creating necessary structures
      for that. But this function was allowed to do so only for SELECT and
      INSERT .. SELECT queries. This makes the SQL_BIG_RESULT useless for
      the CREATE .. SELECT queries.
      
      Now the get_addon_fields allows storing select list items in the filesort
      data for the CREATE .. SELECT queries.
      
      
      mysql-test/t/create.test:
        Added a test case for the bug#15130: CREATE .. SELECT was denied to use
        advantages of the SQL_BIG_RESULT.
      mysql-test/r/create.result:
        Added a test case for the bug#15130: CREATE .. SELECT was denied to use
        advantages of the SQL_BIG_RESULT.
      sql/filesort.cc:
        Bug#15130: CREATE .. SELECT was denied to use advantages of the SQL_BIG_RESULT.
        Now the get_addon_fields allows storing select list items in the filesort
        data for the CREATE .. SELECT queries.
      c4d53e31
    • unknown's avatar
      Merge xiphis.org:/anubis/antony/work/p2-bug25714.1 · 594d71a4
      unknown authored
      into  xiphis.org:/anubis/antony/work/p2-bug25714.1.merge-5.0
      
      
      594d71a4
    • unknown's avatar
      Bug#25714 · 0f85ae9f
      unknown authored
        "getGeneratedKeys() does not work with FEDERATED table"
        mysql_insert() expected the storage engine to update the row data
        during the write_row() operation with the value of the new auto-
        increment field. The field must be updated when only one row has
        been inserted as mysql_insert() would ignore the thd->last_insert.
        This patch implements HA_STATUS_AUTO support in ha_federated::info()
        and ensures that ha_federated::write_row() does update the row's
        auto-increment value.
        The test case was written in C as the protocol's 'id' value is
        accessible through libmysqlclient and not via SQL statements.
        mysql-test-run.pl was extended to enable running the test binary.
      
      
      mysql-test/mysql-test-run.pl:
        bug25714
          implement support to run C test for bug25714
      sql/ha_federated.cc:
        bug25714
          The storage engine instance property auto_increment_value was not
          being set.
          mysql_insert() requires that the storage engine updates the row with
          the auto-increment value, especially when only inserting one row.
          Implement support for ha_federated::info(HA_STATUS_AUTO)
      tests/Makefile.am:
        bug25714
          build C test for bug
      mysql-test/include/have_bug25714.inc:
        New BitKeeper file ``mysql-test/include/have_bug25714.inc''
      mysql-test/r/federated_bug_25714.result:
        New BitKeeper file ``mysql-test/r/federated_bug_25714.result''
      mysql-test/r/have_bug25714.require:
        New BitKeeper file ``mysql-test/r/have_bug25714.require''
      mysql-test/t/federated_bug_25714.test:
        New BitKeeper file ``mysql-test/t/federated_bug_25714.test''
      tests/bug25714.c:
        New BitKeeper file ``tests/bug25714.c''
      0f85ae9f
  8. 23 Jul, 2007 4 commits
    • unknown's avatar
      Merge gkodinov@bk-internal.mysql.com:/home/bk/mysql-5.0-opt · c29002a5
      unknown authored
      into  magare.gmz:/home/kgeorge/mysql/autopush/B29644-5.0-opt
      
      
      sql/ha_innodb.cc:
        Auto merged
      sql/sql_base.cc:
        Auto merged
      mysql-test/r/innodb_mysql.result:
        5.0-opt merge
      mysql-test/t/innodb_mysql.test:
        5.0-opt merge
      c29002a5
    • unknown's avatar
      Merge ibabaev@bk-internal.mysql.com:/home/bk/mysql-5.0-opt · f76d006a
      unknown authored
      into  olga.mysql.com:/home/igor/mysql-5.0-opt
      
      
      f76d006a
    • unknown's avatar
      table.cc, sql_select.cc: · c38fa3f3
      unknown authored
        Limit the fix for bug 28591 to InnoDB only
      
      
      sql/sql_select.cc:
        Limit the fix for bug 28591 to InnoDB only
      sql/table.cc:
        Limit the fix for bug 28591 to InnoDB only
      c38fa3f3
    • unknown's avatar
      Fixed bug #29611. · d50caace
      unknown authored
      If a primary key is defined over column c of enum type then 
      the EXPLAIN command for a look-up query of the form
        SELECT * FROM t WHERE c=0
      said that the query was with an impossible where condition though the
      query correctly returned non-empty result set when the table indeed 
      contained rows with error empty strings for column c. 
      
      This kind of misbehavior was due to a bug in the function 
      Field_enum::store(longlong,bool) that erroneously returned 1 if
      the the value to be stored was equal to 0. 
      Note that the method 
      Field_enum::store(const char *from,uint length,CHARSET_INFO *cs)
      correctly returned 0 if a value of the error empty string 
      was stored. 
      
      
      mysql-test/r/type_enum.result:
        Added a test case for bug #29661.
      mysql-test/t/type_enum.test:
        Added a test case for bug #29661.
      sql/field.cc:
        Fixed bug #29611.
        If a primary key was defined over column c of enum type then 
        the EXPLAIN command for a look-up query of the form
          SELECT * FROM t WHERE c=0
        said that the query was with an impossible where condition though the
        query correctly returned non-empty result set when the table indeed 
        contained rows with error empty strings for column c. 
        
        This kind of misbehavior was due to a bug in the function 
        Field_enum::store(longlong,bool) that erroneously returned 1 if
        the the value to be stored was equal to 0. 
        Note that the method 
        Field_enum::store(const char *from,uint length,CHARSET_INFO *cs)
        correctly returned 0 if a value of the error empty string 
        was stored.
      d50caace
  9. 22 Jul, 2007 4 commits