An error occurred fetching the project authors.
  1. 01 Jul, 2006 1 commit
    • dlenev@mysql.com's avatar
      Fix for bug#18437 "Wrong values inserted with a before update trigger on · d4450e66
      dlenev@mysql.com authored
      NDB table".
      
      SQL-layer was not marking fields which were used in triggers as such. As
      result these fields were not always properly retrieved/stored by handler
      layer. So one might got wrong values or lost changes in triggers for NDB,
      Federated and possibly InnoDB tables.
      This fix solves the problem by marking fields used in triggers
      appropriately.
      
      Also this patch contains the following cleanup of ha_ndbcluster code:
      
      We no longer rely on reading LEX::sql_command value in handler in order
      to determine if we can enable optimization which allows us to handle REPLACE
      statement in more efficient way by doing replaces directly in write_row()
      method without reporting error to SQL-layer.
      Instead we rely on SQL-layer informing us whether this optimization
      applicable by calling handler::extra() method with
      HA_EXTRA_WRITE_CAN_REPLACE flag.
      As result we no longer apply this optimzation in cases when it should not
      be used (e.g. if we have on delete triggers on table) and use in some
      additional cases when it is applicable (e.g. for LOAD DATA REPLACE).
      
      Finally this patch includes fix for bug#20728 "REPLACE does not work
      correctly for NDB table with PK and unique index".
        
      This was yet another problem which was caused by improper field mark-up.
      During row replacement fields which weren't explicity used in REPLACE
      statement were not marked as fields to be saved (updated) so they have
      retained values from old row version. The fix is to mark all table
      fields as set for REPLACE statement. Note that in 5.1 we already solve
      this problem by notifying handler that it should save values from all
      fields only in case when real replacement happens.
      d4450e66
  2. 26 Jun, 2006 2 commits
    • konstantin@mysql.com's avatar
      A fix and a test case for · 117b76a5
      konstantin@mysql.com authored
       Bug#19022 "Memory bug when switching db during trigger execution"
       Bug#17199 "Problem when view calls function from another database."
       Bug#18444 "Fully qualified stored function names don't work correctly in
                  SELECT statements"
      
       Documentation note: this patch introduces a change in behaviour of prepared
       statements.
      
       This patch adds a few new invariants with regard to how THD::db should
       be used. These invariants should be preserved in future:
      
        - one should never refer to THD::db by pointer and always make a deep copy
          (strmake, strdup)
        - one should never compare two databases by pointer, but use strncmp or
          my_strncasecmp
        - TABLE_LIST object table->db should be always initialized in the parser or
          by creator of the object.
      
          For prepared statements it means that if the current database is changed
          after a statement is prepared, the database that was current at prepare
          remains active. This also means that you can not prepare a statement that
          implicitly refers to the current database if the latter is not set.
          This is not documented, and therefore needs documentation. This is NOT a
          change in behavior for almost all SQL statements except:
           - ALTER TABLE t1 RENAME t2 
           - OPTIMIZE TABLE t1
           - ANALYZE TABLE t1
           - TRUNCATE TABLE t1 --
           until this patch t1 or t2 could be evaluated at the first execution of
           prepared statement. 
      
           CURRENT_DATABASE() still works OK and is evaluated at every execution
           of prepared statement.
      
           Note, that in stored routines this is not an issue as the default
           database is the database of the stored procedure and "use" statement
           is prohibited in stored routines.
      
        This patch makes obsolete the use of check_db_used (it was never used in the
        old code too) and all other places that check for table->db and assign it
        from THD::db if it's NULL, except the parser.
      
       How this patch was created: THD::{db,db_length} were replaced with a
       LEX_STRING, THD::db. All the places that refer to THD::{db,db_length} were
       manually checked and:
        - if the place uses thd->db by pointer, it was fixed to make a deep copy
        - if a place compared two db pointers, it was fixed to compare them by value
          (via strcmp/my_strcasecmp, whatever was approproate)
       Then this intermediate patch was used to write a smaller patch that does the
       same thing but without a rename.
      
       TODO in 5.1:
         - remove check_db_used
         - deploy THD::set_db in mysql_change_db
      
       See also comments to individual files.
      117b76a5
    • ingo@mysql.com's avatar
      Bug#16986 - Deadlock condition with MyISAM tables · d27a15a8
      ingo@mysql.com authored
      Addendum fixes after changing the condition variable
      for the global read lock.
      
      The stress test suite revealed some deadlocks. Some were
      related to the new condition variable (COND_global_read_lock)
      and some were general problems with the global read lock.
      
      It is now necessary to signal COND_global_read_lock whenever 
      COND_refresh is signalled.
      
      We need to wait for the release of a global read lock if one 
      is set before every operation that requires a write lock.
      But we must not wait if we have locked tables by LOCK TABLES.
      After setting a global read lock a thread waits until all
      write locks are released.
      d27a15a8
  3. 23 Jun, 2006 1 commit
  4. 01 Jun, 2006 1 commit
    • svoj@may.pils.ru's avatar
      BUG#19192 - CHECK TABLE EXTENDED / REPAIR TABLE show no errors. · 77ab3b28
      svoj@may.pils.ru authored
                  ALTER TABLE crashes
      Executing fast alter table (one that doesn't need to copy data)
      on tables created by mysql versions prior to 4.0.25 could result
      in posterior server crash when accessing these tables.
      
      There was a bug prior to mysql-4.0.25. Number of null fields was
      calculated incorrectly. As a result frm and data files gets out of
      sync after fast alter table. There is no way to determine by which
      mysql version (in 4.0 and 4.1 branches) table was created, thus we
      disable fast alter table for all tables created by mysql versions
      prior to 5.0 branch.
      See BUG#6236.
      77ab3b28
  5. 30 May, 2006 1 commit
    • gluh@eagle.intranet.mysql.r18.ru's avatar
      Bug#17204 "second CALL to procedure crashes Server" · ae72df07
      gluh@eagle.intranet.mysql.r18.ru authored
      Bug#18282 "INFORMATION_SCHEMA.TABLES provides inconsistent info about invalid views"
      This bug caused crashes or resulted in wrong data being returned
      when one tried to obtain information from I_S tables about views
      using stored functions.
      
      It was caused by the fact that we were using LEX representing
      statement which were doing select from I_S tables as active LEX
      when contents of I_S table were built. So state of this LEX both
      affected and was affected by open_tables() calls which happened
      during this process. This resulted in wrong behavior and in
      violations of some of invariants which caused crashes.
      
      This fix tries to solve this problem by properly saving/resetting
      and restoring part of LEX which affects and is affected by the
      process of opening tables and views in get_all_tables() routine.
      To simplify things we separated this part of LEX in a new class
      and made LEX its descendant.
      ae72df07
  6. 16 May, 2006 1 commit
    • svoj@april.(none)'s avatar
      BUG#17001 - Table and server crash on ALTER TABLE · 3afbfc5f
      svoj@april.(none) authored
      frm and data files for tables created by earlier MySQL
      versions becomes out of sync after certain ALTER TABLE statements:
      - One that changes column default value;
      - One that changes table comment;
      - One that changes table password.
      
      As a result one can expirience either server crash or data corruption/loss.
      
      This fix ensures that running ALTER TABLE on tables created by earlier
      MySQL versions recreates data files.
      3afbfc5f
  7. 09 May, 2006 2 commits
    • acurtis@xiphis.org's avatar
      bug#10952 · 47e89f20
      acurtis@xiphis.org authored
        "alter table from MyISAM to MERGE lost data without errors and warnings"
        Add new handlerton flag which prevent user from altering table storage
        engine to storage engines which would lose data. Both 'blackhole' and 
        'merge' are marked with the new flag.
        Tests included.
      47e89f20
    • dlenev@mysql.com's avatar
      Fix for bugs#12472/#15137 'CREATE TABLE ... SELECT ... which explicitly · 589daad1
      dlenev@mysql.com authored
      or implicitly uses stored function gives "Table not locked" error'
      
      CREATE TABLE ... SELECT ... statement which was explicitly or implicitly
      (through view) using stored function gave "Table not locked" error.
      
      The actual bug resides in the current locking scheme of CREATE TABLE SELECT
      code, which first opens and locks tables of the SELECT statement itself,
      and then, having SELECT tables locked, creates the .FRM, opens the .FRM and
      acquires lock on it. This scheme opens a possibility for a deadlock, which
      was present and ignored since version 3.23 or earlier. This scheme also
      conflicts with the invariant of the prelocking algorithm -- no table can
      be open and locked while there are tables locked in prelocked mode.
      
      The patch makes an exception for this invariant when doing CREATE TABLE ...
      SELECT, thus extending the possibility of a deadlock to the prelocked mode.
      We can't supply a better fix in 5.0.
      589daad1
  8. 03 May, 2006 1 commit
  9. 28 Apr, 2006 1 commit
  10. 25 Apr, 2006 1 commit
  11. 12 Apr, 2006 1 commit
  12. 30 Mar, 2006 1 commit
  13. 29 Mar, 2006 2 commits
    • evgen@moonbone.local's avatar
      Fixed bug#15560: GROUP_CONCAT wasn't ready for WITH ROLLUP queries · 1c13e548
      evgen@moonbone.local authored
      The GROUP_CONCAT uses its own temporary table. When ROLLUP is present
      it creates the second copy of Item_func_group_concat. This copy receives the
      same list of arguments that original group_concat does. When the copy is
      set up the result_fields of functions from the argument list are reset to the
      temporary table of this copy.
      As a result of this action data from functions flow directly to the ROLLUP copy
      and the original group_concat functions shows wrong result.
      Since queries with COUNT(DISTINCT ...) use temporary tables to store
      the results the COUNT function they are also affected by this bug.
      
      The idea of the fix is to copy content of the result_field for the function
      under GROUP_CONCAT/COUNT from  the first temporary table to the second one,
      rather than setting result_field to point to the second temporary table.
      To achieve this goal force_copy_fields flag is added to Item_func_group_concat
      and Item_sum_count_distinct classes. This flag is initialized to 0 and set to 1
      into the make_unique() member function of both classes.
      To the TMP_TABLE_PARAM structure is modified to include the similar flag as
      well.
      The create_tmp_table() function passes that flag to create_tmp_field().
      When the flag is set the create_tmp_field() function will set result_field
      as a source field and will not reset that result field to newly created 
      field for Item_func_result_field and its descendants. Due to this there
      will be created copy func to copy data from old result_field to newly 
      created field.
      1c13e548
    • gluh@eagle.intranet.mysql.r18.ru's avatar
      Fix for bug#15316 SET value having comma not correctly handled · 2545c7d4
      gluh@eagle.intranet.mysql.r18.ru authored
       disallow the use of comma in SET members
      2545c7d4
  14. 24 Mar, 2006 2 commits
    • dlenev@mysql.com's avatar
      Follow-up for the fix for bug #18153 "ALTER/OPTIMIZE/REPAIR on transactional · 4d1d8ed3
      dlenev@mysql.com authored
      tables corrupt triggers".
      
      It turned out that we also have relied at certain places that
      (new_table != table_name) were always true on Windows and for transactional
      tables. Since our fix for the bug brakes this assumption we have to add new
      flag to pass this information around.
      This code needs to be refactored but I dare not to do this in 5.0.
      4d1d8ed3
    • dlenev@mysql.com's avatar
      Fix for bug #18153 "ALTER/OPTIMIZE/REPAIR on transactional tables corrupt · 891e9424
      dlenev@mysql.com authored
      triggers".
      
      Applying ALTER/OPTIMIZE/REPAIR TABLE statements to transactional table or to
      table of any type on Windows caused disappearance of its triggers.
      Bug was introduced in 5.0.19 by my fix for bug #13525 "Rename table does not
      keep info of triggers" (see comment for sql_table.cc for more info).
      .
      891e9424
  15. 24 Feb, 2006 1 commit
  16. 21 Feb, 2006 2 commits
    • konstantin@mysql.com's avatar
      A fix and a test case for Bug#13134 "Length of VARCHAR() utf8 · 442c2ba8
      konstantin@mysql.com authored
      column is increasing when table is recreated with PS/SP":
      make use of create_field::char_length more consistent in the code.
      Reinit create_field::length from create_field::char_length
      for every execution of a prepared statement (actually fixes the 
      bug).
      442c2ba8
    • evgen@moonbone.local's avatar
      Fixed bug#17530: Incorrect key truncation on table creation caused server crash. · e6924206
      evgen@moonbone.local authored
      When a too long field is used for a key, only a prefix part of the field is 
      used. Length is reduced to the max key length allowed for storage. But if the
      field have a multibyte charset it is possible to break multibyte char
      sequence. This leads to the failed assertion in the innodb code and 
      server crash when a record is inserted.
      
      The make_prepare_table() now aligns truncated key length to the boundary of
      multibyte char.
      e6924206
  17. 17 Feb, 2006 1 commit
  18. 01 Feb, 2006 1 commit
    • ingo@mysql.com's avatar
      Bug#8841 - CHECKSUM TABLE is broken in MyISAM · c5a7bffc
      ingo@mysql.com authored
      There are (at least) two implementations of the checksum
      computation. One is in MyISAM for the quick checksum. It
      is executed on every row change. The other is in the
      SQL layer for the extended checksum. It retrieves all rows
      of a table via the respective storage engine.
      
      In former MySQL versions varchars were stored with their 
      maximum length, but now with their real length similar to
      blobs.
      
      This change had been forgotten to take care of in the
      extended checksum calculation. Hence too much data was
      checksumed. In MyISAM this change had been taken care of 
      already. Only the real data is included in the checksum.
      
      I changed mysql_checksum_table() so that it uses the
      length information of true varchar fields instead
      of the field length like in former varchar 
      implementations.
      c5a7bffc
  19. 13 Jan, 2006 1 commit
  20. 10 Dec, 2005 1 commit
  21. 05 Dec, 2005 1 commit
  22. 03 Dec, 2005 1 commit
  23. 25 Nov, 2005 2 commits
  24. 24 Nov, 2005 1 commit
  25. 20 Nov, 2005 1 commit
    • bell@sanja.is.com.ua's avatar
      Inefficient usage of String::append() fixed. · 806f9e24
      bell@sanja.is.com.ua authored
      Bad examples of usage of a string with its length fixed.
      The incorrect length in the trigger file configuration descriptor
        fixed (BUG#14090).
      A hook for unknown keys added to the parser to support old .TRG files.
      806f9e24
  26. 15 Nov, 2005 1 commit
    • ingo@mysql.com's avatar
      Bug#14397 - OPTIMIZE TABLE with an open HANDLER causes a crash · 74781d65
      ingo@mysql.com authored
      Version for 5.0.
      It fixes three problems:
      1. The cause of the bug was that we did not check the table version for
       the HANDLER ... READ commands. We did not notice when a table was
       replaced by a new one. This can happen during ALTER TABLE, REPAIR
       TABLE, and OPTIMIZE TABLE (there might be more cases). I call the fix
       for this problem "the primary bug fix".
      2. mysql_ha_flush() was not always called with a locked LOCK_open.
       Though the function comment clearly said it must.
       I changed the code so that the locking is done when required. I call
       the fix for this problem "the secondary fix".
      3. In 5.0 (not in 4.1 or 4.0) DROP TABLE had a possible deadlock flaw in
       concur with FLUSH TABLES WITH READ LOCK. I call the fix for this
       problem "the 5.0 addendum fix".
      74781d65
  27. 09 Nov, 2005 1 commit
  28. 07 Nov, 2005 1 commit
  29. 06 Nov, 2005 1 commit
  30. 03 Nov, 2005 4 commits
  31. 02 Nov, 2005 1 commit
    • igor@rurik.mysql.com's avatar
      #view.test#: · fddc99bc
      igor@rurik.mysql.com authored
        new file
      sql_table.cc, handler.h:
        Fixed bug #14540.
        Added error mnemonic code HA_ADMIN_NOT_BASE_TABLE
        to report that an operation cannot be applied for views.
      view.test, view.result:
        Added a test case for bug #14540.
      errmsg.txt:
        Fixed bug #14540.
        Added error ER_CHECK_NOT_BASE_TABLE.
      fddc99bc