1. 02 Aug, 2007 1 commit
  2. 01 Aug, 2007 2 commits
    • unknown's avatar
      Merge chilla.local:/home/mydev/mysql-4.1-bug29838 · 374ff879
      unknown authored
      into  chilla.local:/home/mydev/mysql-5.0-bug29838
      
      
      myisam/mi_rkey.c:
        Auto merged
      374ff879
    • unknown's avatar
      Bug#29838 - myisam corruption using concurrent select ... and update · 4158e75d
      unknown authored
      When using concurrent insert with parallel index reads, it could
      happen that reading sessions found keys that pointed to records
      yet to be written to the data file. The result was a report of
      a corrupted table. But it was false alert.
      
      When inserting a record in a table with indexes, the keys are
      inserted into the indexes before the record is written to the data
      file. When the insert happens concurrently to selects, an
      index read can find a key that references the record that is not
      yet written to the data file. To avoid any access to such record,
      the select saves the current end of file position when it starts.
      Since concurrent inserts are always appended at end of the data
      file, the select can easily ignore any concurrently inserted record.
      
      The problem was that the ignore was only done for non-exact key
      searches (partial key or using >, >=, < or <=).
      
      The fix is to ignore concurrently inserted records also for
      exact key searches.
      
      No test case. Concurrent inserts cannot be tested with the test
      suite. Test cases are attached to the bug report.
      
      
      myisam/mi_rkey.c:
        Bug#29838 - myisam corruption using concurrent select ... and update
        Fixed mi_rkey() to always ignore records beyond saved eof.
      4158e75d
  3. 31 Jul, 2007 1 commit
    • unknown's avatar
      BUG#29152 - INSERT DELAYED does not use concurrent_insert on slave · 8018d6ac
      unknown authored
      INSERT DELAYED on a replication slave was converted to regular INSERT,
      whereas it should try concurrent INSERT first.
      
      With this patch we try to convert delayed insert to concurrent insert on
      a replication slave. If it is impossible for some reason, we fall back to
      regular insert.
      
      No test case for this fix. I do not see anything indicating this is
      regression - we behave this way since Nov 2000.
      
      
      sql/sql_insert.cc:
        If we're executing INSERT DELAYED on a replication slave, we're upgrading
        lock type to TL_WRITE as we need to ensure serial execution of queries on
        the slave.
        
        OTOH if we're executing regular INSERT on a replication slave, we're
        trying TL_WRITE_CONCURRENT_INSERT first, and if we may not use it, we
        fall back to TL_WRITE.
        
        Fixed INSERT DELAYED on a replication slave to behave the same way as
        regular INSERT, that is to try TL_WRITE_CONCURRENT_INSERT first.
      8018d6ac
  4. 28 Jul, 2007 2 commits
  5. 27 Jul, 2007 2 commits
    • 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
  6. 26 Jul, 2007 2 commits
  7. 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
  8. 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
  9. 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
  10. 22 Jul, 2007 5 commits
  11. 21 Jul, 2007 9 commits
  12. 20 Jul, 2007 3 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