1. 26 Jul, 2007 2 commits
  2. 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
  3. 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
  4. 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
  5. 22 Jul, 2007 5 commits
  6. 21 Jul, 2007 9 commits
  7. 20 Jul, 2007 11 commits
    • unknown's avatar
      Merge kboortz@bk-internal.mysql.com:/home/bk/mysql-5.0 · 47507276
      unknown authored
      into  mysql.com:/home/kent/bk/tmp3/mysql-5.0-build
      
      
      libmysql/libmysql.c:
        Auto merged
      scripts/make_binary_distribution.sh:
        Auto merged
      sql/field.cc:
        Auto merged
      47507276
    • unknown's avatar
      Fixed bug #29788. · cff531ff
      unknown authored
      After dumping triggers mysqldump copied 
      the value of the OLD_SQL_MODE variable to the SQL_MODE
      variable. If the --compact option of the mysqldump was
      not set the OLD_SQL_MODE variable had the value
      of the uninitialized SQL_MODE variable. So
      usually the NO_AUTO_VALUE_ON_ZERO option of the
      SQL_MODE variable was discarded.
      
      This fix is for non-"--compact" mode of the mysqldump,
      because mysqldump --compact never set SQL_MODE to the
      value of NO_AUTO_VALUE_ON_ZERO.
      
      The dump_triggers_for_table function has been modified
      to restore previous value of the SQL_MODE variable after
      dumping triggers using the SAVE_SQL_MODE temporary
      variable.
      
      
      client/mysqldump.c:
        Fixed bug #29788.
        The dump_triggers_for_table function has been modified
        to restore previous value of the SQL_MODE variable after
        dumping triggers using the SAVE_SQL_MODE temporary
        variable.
      mysql-test/r/mysqldump.result:
        Updated test case for bug #29788.
      mysql-test/t/mysqldump.test:
        Updated test case for bug #29788.
      cff531ff
    • unknown's avatar
      Merge chilla.local:/home/mydev/mysql-5.0-amain · 524a40a9
      unknown authored
      into  chilla.local:/home/mydev/mysql-5.0-axmrg
      
      
      524a40a9
    • unknown's avatar
      Merge chilla.local:/home/mydev/mysql-5.0-ateam · 4ae56e21
      unknown authored
      into  chilla.local:/home/mydev/mysql-5.0-axmrg
      
      
      4ae56e21
    • unknown's avatar
      Bug #28591: MySQL need not sort the records in case of · 95a8c6c3
      unknown authored
      ORDER BY primary_key on InnoDB table
      
      Queries that use an InnoDB secondary index to retrieve
      data don't need to sort in case of ORDER BY primary key
      if the secondary index is compared to constant(s).
      They can also skip sorting if ORDER BY contains both the
      the secondary key parts and the primary key parts (in
      that order).
      This is because InnoDB returns the rows in order of the
      primary key for rows with the same values of the secondary
      key columns.
      Fixed by preventing temp table sort for the qualifying 
      queries.
      
      
      mysql-test/r/innodb_mysql.result:
        Bug #28591: test case
      mysql-test/t/innodb_mysql.test:
        Bug #28591: test case
      sql/sql_select.cc:
        Bug #28591: Use the primary key as suffix when testing
        if the key can be used for ORDER BY on supporting engines.
      sql/table.cc:
        Bug #28591: can use the primary key
        as a suffix for the secondary keys
      95a8c6c3
    • unknown's avatar
      Merge epotemkin@bk-internal.mysql.com:/home/bk/mysql-5.0-opt · d758b1e6
      unknown authored
      into  moonbone.local:/mnt/gentoo64/work/29898-bug-5.0-opt-mysql
      
      
      d758b1e6
    • unknown's avatar
      Remove obvious comments. · 7a99db0b
      unknown authored
      7a99db0b
    • unknown's avatar
      Merge trift-lap.none:/MySQL/M50/bug14151-5.0 · 366c21fe
      unknown authored
      into  trift-lap.none:/MySQL/M50/push-5.0
      
      
      366c21fe
    • unknown's avatar
      Bug #29644: alter table hangs if records locked in share mode · eea5c2a3
      unknown authored
      by long running transaction
      
      On Windows opened files can't be deleted. There was a special
      upgraded lock mode (TL_WRITE instead of TL_WRITE_ALLOW_READ) 
      in ALTER TABLE to make sure nobody has the table opened
      when deleting the old table in ALTER TABLE. This special mode
      was causing ALTER TABLE to hang waiting on a lock inside InnoDB.
      This special lock is no longer necessary as the server is 
      closing the tables it needs to delete in ALTER TABLE.
      Fixed by removing the special lock.
      Note that this also reverses the fix for bug 17264 that deals with
      another consequence of this special lock mode being used.
      
      
      mysql-test/r/innodb_mysql.result:
        Bug #29644: test case
      mysql-test/t/innodb_mysql.test:
        Bug #29644: test case
      sql/ha_innodb.cc:
        Bug #29644: reverse the (now excessive) fix
        for bug 17264 (but leave the test case).
      sql/sql_base.cc:
        Bug #29644: don't need a special lock mode for Win32 anymore: 
        the table is closed before the drop.
      eea5c2a3
    • unknown's avatar
      Bug #29494 Field packet with NULL fields crashes libmysqlclient. · 1a2d2117
      unknown authored
      unpack_fields() didn't expect NULL_LENGHT in the field's descriptions.
      In this case we get NULL in the resulting string so cannot use
      strdup_root to make a copy of it.
      strdup_root changed with strmake_root as it's NULL-safe
      
      
      sql-common/client.c:
        Bug #29494 Field packet with NULL fields crashes libmysqlclient
        
        strdup_root changed with strmake_root in unpack_fields()
      1a2d2117
    • unknown's avatar
      Merge pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-5.0.46 · d8305ab9
      unknown authored
      into  pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-5.0-build
      
      
      configure.in:
        Auto merged
      libmysql/libmysql.c:
        Auto merged
      scripts/make_binary_distribution.sh:
        Auto merged
      sql/field.cc:
        Auto merged
      d8305ab9