1. 26 Jun, 2006 1 commit
    • unknown's avatar
      Bug#16218 - Crash on insert delayed · ab5ebc0f
      unknown authored
      Bug#17294 - INSERT DELAYED puting an \n before data
      Bug#16611 - INSERT DELAYED corrupts data
      Bug#13707 - Server crash with INSERT DELAYED on MyISAM table
      Combined as Bug#16218.
      
      INSERT DELAYED crashed in 5.0 on a table with a varchar that 
      could be NULL and was created pre-5.0 (Bugs 16218 and 13707).
      INSERT DELAYED corrupted data in 5.0 on a table with varchar 
      fields that was created pre-5.0 (Bugs 17294 and 16611).
      
      In case of INSERT DELAYED the open table is copied from the
      delayed insert thread to be able to create a record for the 
      queue. When copying the fields, a method was used that did 
      convert old varchar to new varchar fields and did not set up 
      some pointers into the record buffer of the table.
      
      The field conversion was guilty for the misinterpretation of 
      the record contents by the delayed insert thread. The wrong
      pointer setup was guilty for the crashes.
      
      For Bug 13707 (Server crash with INSERT DELAYED on MyISAM table)
      I fixed the above mentioned method to set up one of the pointers.
      For Bug 16218 I set up the other pointers too.
      
      But when looking at the corruptions I got aware that converting
      the field type was totally wrong for INSERT DELAYED. The copied
      table is used to create a record that is to be sent to the
      delayed insert thread. Of course it can interpret the record
      correctly only if all field types are the same in both table
      objects.
      
      So I revoked the fix for Bug 13707 and changed the new_field() 
      method so that it can suppress conversions.
      
      No test case as this is a migration problem. One needs to
      create a table with 4.x and use it with 5.x. I added two
      test scripts to the bug report.
      
      
      sql/field.cc:
        Bug#16218 - Crash on insert delayed
        Bug#17294 - INSERT DELAYED puting an \n before data
        Bug#16611 - INSERT DELAYED corrupts data
        Bug#13707 - Server crash with INSERT DELAYED on MyISAM table
        Combined as Bug#16218.
        
        Added parameter 'keep_type' to Field::new_field().
        
        Undid the change from Bug 13707 (Server crash with INSERT 
        DELAYED on MyISAM table).
        I solved all four bugs in sql/sql_insert.cc by making exact
        duplicates of the fields. The new_field() method converts
        certain field types, which is wrong for INSERT DELAYED.
      sql/field.h:
        Bug#13707 - Server crash with INSERT DELAYED on MyISAM table
        Combined as Bug#16218.
        
        Added parameter 'keep_type' to Field::new_field().
      sql/sql_insert.cc:
        Bug#16218 - Crash on insert delayed
        Bug#17294 - INSERT DELAYED puting an \n before data
        Bug#16611 - INSERT DELAYED corrupts data
        Bug#13707 - Server crash with INSERT DELAYED on MyISAM table
        Combined as Bug#16218.
        
        Added comments. Made small style fixes.
        Used the new parameter 'keep_type' of Field::new_field()
        to avoid field type conversion. The table copy must have
        exactly the same types of fields as the original table.
        Otherwise the record contents created by the foreground 
        thread could be misinterpreted by the delayed insert thread.
      sql/sql_select.cc:
        Bug#16218 - Crash on insert delayed
        Bug#17294 - INSERT DELAYED puting an \n before data
        Bug#16611 - INSERT DELAYED corrupts data
        Bug#13707 - Server crash with INSERT DELAYED on MyISAM table
        Combined as Bug#16218.
        
        Added parameter 'keep_type' to Field::new_field().
        
        Undid the change from Bug 13707 (Server crash with INSERT 
        DELAYED on MyISAM table).
        I solved all four bugs in sql/sql_insert.cc by making exact
        duplicates of the fields. The new_field() method converts
        certain field types, which is wrong for INSERT DELAYED.
      sql/sql_trigger.cc:
        Bug#16218 - Crash on insert delayed
        Bug#17294 - INSERT DELAYED puting an \n before data
        Bug#16611 - INSERT DELAYED corrupts data
        Bug#13707 - Server crash with INSERT DELAYED on MyISAM table
        Combined as Bug#16218.
        
        Added parameter 'keep_type' to Field::new_field().
        
        Undid the change from Bug 13707 (Server crash with INSERT 
        DELAYED on MyISAM table).
        I solved all four bugs in sql/sql_insert.cc by making exact
        duplicates of the fields. The new_field() method converts
        certain field types, which is wrong for INSERT DELAYED.
      sql/table.cc:
        Bug#16218 - Crash on insert delayed
        Bug#17294 - INSERT DELAYED puting an \n before data
        Bug#16611 - INSERT DELAYED corrupts data
        Bug#13707 - Server crash with INSERT DELAYED on MyISAM table
        Combined as Bug#16218.
        
        Added parameter 'keep_type' to Field::new_field().
        
        Undid the change from Bug 13707 (Server crash with INSERT 
        DELAYED on MyISAM table).
        I solved all four bugs in sql/sql_insert.cc by making exact
        duplicates of the fields. The new_field() method converts
        certain field types, which is wrong for INSERT DELAYED.
      ab5ebc0f
  2. 31 May, 2006 3 commits
    • unknown's avatar
      Merge mysql.com:/home/mydev/mysql-5.0 · 8efe592d
      unknown authored
      into  mysql.com:/home/mydev/mysql-5.0-bug19604
      
      
      8efe592d
    • unknown's avatar
      Bug#19604 - CHECK TABLE with concurrent INSERT can reset auto_increment · 4a1d0763
      unknown authored
      CHECK TABLE did temporarily clear the auto_increment value.
      It runs with a read lock, allowing other readers and
      conurrent INSERTs. The latter could grab the wrong value
      in this moment.
      
      CHECK TABLE does no longer modify the auto_increment value.
      Not even for a short moment.
      
      
      myisam/mi_check.c:
        Bug#19604 - CHECK TABLE with concurrent INSERT can reset auto_increment
        In chk_key() and update_auto_increment_key() in the repair_only
        case, do not touch info->s->state.auto_increment. Especially
        chk_key() can be called from CHECK TABLE with a read lock.
        Concurrent inserts could grab a temporarily changed value.
        Added minor style fixes.
      myisam/mi_key.c:
        Bug#19604 - CHECK TABLE with concurrent INSERT can reset auto_increment
        Changed update_auto_increment() to retrieve_auto_increment()
        to reflect that it does not change the auto_increment by
        itself any more. This must now be done externally if needed.
      myisam/mi_update.c:
        Bug#19604 - CHECK TABLE with concurrent INSERT can reset auto_increment
        Added explicit update of info->s->state.auto_increment
        after the change from update_auto_increment() to
        retrieve_auto_increment().
      myisam/mi_write.c:
        Bug#19604 - CHECK TABLE with concurrent INSERT can reset auto_increment
        Added explicit update of info->s->state.auto_increment
        after the change from update_auto_increment() to
        retrieve_auto_increment().
      myisam/myisamdef.h:
        Bug#19604 - CHECK TABLE with concurrent INSERT can reset auto_increment
        Changed update_auto_increment() to retrieve_auto_increment()
        to reflect that it does not change the auto_increment by
        itself any more. This must now be done externally if needed.
      4a1d0763
    • unknown's avatar
      Bug#19648 · 11dbc1c4
      unknown authored
        "Merge table does not work with bit types"
         MERGE should have HA_CAN_BIT_FIELD feature bit set or else table row is
         formatted incorrectly.
      
      
      mysql-test/r/merge.result:
        Bug#19648
          Test for fix
      mysql-test/t/merge.test:
        Bug#19648
          Test for fix
      sql/ha_myisammrg.h:
        Bug#19648
          Must have HA_CAN_BIT_FIELD for BIT type support
      11dbc1c4
  3. 29 May, 2006 1 commit
    • unknown's avatar
      Bug#19815 - CREATE/RENAME/DROP DATABASE can deadlock on a global read lock · 4f8407b6
      unknown authored
      The order of acquiring LOCK_mysql_create_db
      and wait_if_global_read_lock() was wrong. It could happen
      that a thread held LOCK_mysql_create_db while waiting for
      the global read lock to be released. The thread with the
      global read lock could try to administrate a database too.
      It would first try to lock LOCK_mysql_create_db and hang...
      
      The check if the current thread has the global read lock
      is done in wait_if_global_read_lock(), which could not be
      reached because of the hang in LOCK_mysql_create_db.
      
      Now I exchanged the order of acquiring LOCK_mysql_create_db
      and wait_if_global_read_lock(). This makes 
      wait_if_global_read_lock() fail with an error message for
      the thread with the global read lock. No deadlock happens.
      
      
      mysql-test/r/lock_multi.result:
        Bug#19815 - CREATE/RENAME/DROP DATABASE can deadlock on a global read lock
        The test result
      mysql-test/t/lock_multi.test:
        Bug#19815 - CREATE/RENAME/DROP DATABASE can deadlock on a global read lock
        The test case
      sql/sql_db.cc:
        Bug#19815 - CREATE/RENAME/DROP DATABASE can deadlock on a global read lock
        Exchanged the order of acquiring LOCK_mysql_create_db
        and wait_if_global_read_lock().
      4f8407b6
  4. 18 May, 2006 1 commit
  5. 10 May, 2006 1 commit
    • unknown's avatar
      BUG#18233 - Memory tables INDEX USING HASH (a,b) returns 1 row on · 2eeab0b0
      unknown authored
                  SELECT WHERE a= AND b=
      
      Selecting data from memory table with varchar column and hash index over it
      returns only first row matched.
      
      Problem was that key length calculation for varchar columns didn't include
      number of bytes to store length.
      
      Fixed key length for varchar fields to include number of bytes to store length.
      
      
      heap/hp_create.c:
        Fixed key length for varchar fields to include number of bytes to store length.
      mysql-test/r/heap.result:
        Testcase for BUG#18233.
      mysql-test/t/heap.test:
        Testcase for BUG#18233.
      2eeab0b0
  6. 09 May, 2006 8 commits
  7. 08 May, 2006 5 commits
    • unknown's avatar
      No commit message · 42f20d75
      unknown authored
      No commit message
      42f20d75
    • unknown's avatar
      Merge mysql.com:/Users/kent/mysql/bk/mysql-5.0-release · db122e94
      unknown authored
      into mysql.com:/Users/kent/mysql/bk/mysql-5.0-new
      
      
      configure.in:
        Auto merged
      db122e94
    • unknown's avatar
      Remove valgrind and compiler warnings · bc324937
      unknown authored
      Add function 'vio_end' that will cleanup resources allocated by vio and the components it uses.
      
      
      include/violite.h:
        Import patch warnings.patch
      libmysql/libmysql.c:
        Import patch warnings.patch
      sql/mysqld.cc:
        Import patch warnings.patch
      vio/test-ssl.c:
        Import patch warnings.patch
      vio/test-sslclient.c:
        Import patch warnings.patch
      vio/test-sslserver.c:
        Import patch warnings.patch
      vio/vio.c:
        Import patch warnings.patch
      vio/viosslfactories.c:
        Import patch warnings.patch
      bc324937
    • unknown's avatar
      Merge neptunus.(none):/home/msvensson/mysql/my50-maint-bug18474 · c593d1f1
      unknown authored
      into  neptunus.(none):/home/msvensson/mysql/mysql-5.0-maint
      
      
      c593d1f1
    • unknown's avatar
      Merge 192.168.0.20:mysql/my50-maint-yassl · fa91c7bc
      unknown authored
      into  neptunus.(none):/home/msvensson/mysql/mysql-5.0-maint
      
      
      extra/yassl/src/ssl.cpp:
        Auto merged
      extra/yassl/taocrypt/src/make.bat:
        Auto merged
      extra/yassl/testsuite/test.hpp:
        Auto merged
      fa91c7bc
  8. 07 May, 2006 10 commits
    • unknown's avatar
      Merge ibabaev@bk-internal.mysql.com:/home/bk/mysql-5.0 · 47302570
      unknown authored
      into  rurik.mysql.com:/home/igor/mysql-5.0
      
      
      mysql-test/r/rpl_user_variables.result:
        Auto merged
      sql/item_func.cc:
        Auto merged
      sql/sql_select.cc:
        Auto merged
      mysql-test/t/rpl_user_variables.test:
        Manual merge
      47302570
    • unknown's avatar
      Post-merge fixes. · 5aa69d34
      unknown authored
      5aa69d34
    • unknown's avatar
      Merge rurik.mysql.com:/home/igor/dev/mysql-4.1-0 · 30a7094f
      unknown authored
      into  rurik.mysql.com:/home/igor/dev/mysql-5.0-0
      
      
      mysql-test/r/having.result:
        Auto merged
      mysql-test/t/having.test:
        Auto merged
      sql/item_func.cc:
        Auto merged
      sql/sql_lex.h:
        Auto merged
      mysql-test/r/rpl_user_variables.result:
        Manual merge
      mysql-test/t/rpl_user_variables.test:
        Manual merge
      sql/sql_lex.cc:
        Manual merge
      sql/sql_prepare.cc:
        Manual merge
      sql/sql_select.cc:
        Manual merge
      30a7094f
    • unknown's avatar
      Merge ibabaev@bk-internal.mysql.com:/home/bk/mysql-4.1 · e4e67d58
      unknown authored
      into  rurik.mysql.com:/home/igor/mysql-4.1
      
      
      e4e67d58
    • unknown's avatar
      Merge aelkin@bk-internal.mysql.com:/home/bk/mysql-5.0 · c438e490
      unknown authored
      into  mysql.com:/usr_rh9/home/elkin.rh9/MySQL/Merge/5.0-bug19136
      
      
      sql/sql_select.cc:
        Auto merged
      c438e490
    • unknown's avatar
      Bug#19136: Crashing log-bin and uninitialized user variables in a derived table · a910a0bf
      unknown authored
      recalculating results
      
      
      mysql-test/r/rpl_user_variables.result:
        fixing results
      a910a0bf
    • unknown's avatar
    • unknown's avatar
      Merge mysql.com:/usr_rh9/home/elkin.rh9/4.1 · 048469eb
      unknown authored
      into  mysql.com:/usr_rh9/home/elkin.rh9/MySQL/Merge/5.0-bug19136
      
      
      sql/item_func.cc:
        Auto merged
      sql/sql_select.cc:
        Auto merged
      mysql-test/r/rpl_user_variables.result:
        manual merge use local
      mysql-test/t/rpl_user_variables.test:
        manual merge use version 5.0's "show binlog events from 98"
      048469eb
    • unknown's avatar
      Merge mysql.com:/usr_rh9/home/elkin.rh9/MySQL/BARE/4.1 · ce6a2d32
      unknown authored
      into  mysql.com:/usr_rh9/home/elkin.rh9/MySQL/FIXES/4.1-bug19136_unass_user_var
      
      
      sql/item_func.cc:
        Auto merged
      ce6a2d32
    • unknown's avatar
      Fixed bug #14927. · 375749b8
      unknown authored
      A query with a group by and having clauses could return a wrong
      result set if the having condition contained a constant conjunct 
      evaluated to FALSE.
      It happened because the pushdown condition for table with
      grouping columns lost its constant conjuncts.
      Pushdown conditions are always built by the function make_cond_for_table
      that ignores constant conjuncts. This is apparently not correct when
      constant false conjuncts are present.
      
      
      
      mysql-test/r/having.result:
        Added a test case for bug #14927.
      mysql-test/t/having.test:
        Added a test case for bug #14927.
      sql/sql_lex.cc:
        Fixed bug #14927.
        Initialized fields for having conditions in  st_select_lex::init_query().
      sql/sql_lex.h:
        Fixed bug #14927.
        Added a field to restore having condititions for execution in SP and PS.
      sql/sql_prepare.cc:
        Fixed bug #14927.
        Added code to restore havinf conditions for execution in SP and PS.
      sql/sql_select.cc:
        Fixed bug #14927.
        Performed evaluation of constant expressions in having clauses.
        If the having condition contains a constant conjunct that is always false
        an empty result set is returned after the optimization phase.
        In this case the corresponding EXPLAIN command now returns 
        "Impossible HAVING" in the last column.
      375749b8
  9. 06 May, 2006 10 commits