An error occurred fetching the project authors.
  1. 23 Dec, 2006 1 commit
  2. 11 Dec, 2006 1 commit
  3. 07 Dec, 2006 1 commit
    • kostja@bodhi.local's avatar
      A fix and test cases for · 90072e69
      kostja@bodhi.local authored
      Bug#4968 "Stored procedure crash if cursor opened on altered table"
      Bug#19733 "Repeated alter, or repeated create/drop, fails"
      Bug#19182 "CREATE TABLE bar (m INT) SELECT n FROM foo; doesn't work from 
      stored procedure."
      Bug#6895 "Prepared Statements: ALTER TABLE DROP COLUMN does nothing"
      Bug#22060 "ALTER TABLE x AUTO_INCREMENT=y in SP crashes server"
      
      Test cases for bugs 4968, 19733, 6895 will be added in 5.0.
      
      Re-execution of CREATE DATABASE, CREATE TABLE and ALTER TABLE 
      statements in stored routines or as prepared statements caused
      incorrect results (and crashes in versions prior to 5.0.25).
      In 5.1 the problem occured only for CREATE DATABASE, CREATE TABLE
      SELECT and CREATE TABLE with INDEX/DATA DIRECTOY options).
      
      The problem of bugs 4968, 19733, 19282 and 6895 was that functions
      mysql_prepare_table, mysql_create_table and mysql_alter_table were not
      re-execution friendly: during their operation they used to modify contents
      of LEX (members create_info, alter_info, key_list, create_list),
      thus making the LEX unusable for the next execution.
      In particular, these functions removed processed columns and keys from
      create_list, key_list and drop_list. Search the code in sql_table.cc 
      for drop_it.remove() and similar patterns to find evidence.
      
      The fix is to supply to these functions a usable copy of each of the
      above structures at every re-execution of an SQL statement. 
      
      To simplify memory management, LEX::key_list and LEX::create_list
      were added to LEX::alter_info, a fresh copy of which is created for
      every execution.
      
      The problem of crashing bug 22060 stemmed from the fact that the above 
      metnioned functions were not only modifying HA_CREATE_INFO structure in 
      LEX, but also were changing it to point to areas in volatile memory of 
      the execution memory root.
       
      The patch solves this problem by creating and using an on-stack
      copy of HA_CREATE_INFO (note that code in 5.1 already creates and
      uses a copy of this structure in mysql_create_table()/alter_table(),
      but this approach didn't work well for CREATE TABLE SELECT statement).
      90072e69
  4. 28 Nov, 2006 1 commit
    • andrey@example.com's avatar
      Fix for bug#24395: · 100dd45e
      andrey@example.com authored
      ALTER TABLE DISABLE KEYS doesn't work when modifying the table
        
      ENABLE|DISABLE KEYS combined with another ALTER TABLE option, different
      than RENAME TO did nothing. Also, if the table had disabled keys
      and was ALTER-ed then the end table was with enabled keys.
        
      Fixed by checking whether the table had disabled keys and enabling them
      in the copied table.
      100dd45e
  5. 16 Nov, 2006 2 commits
  6. 01 Nov, 2006 1 commit
    • igor@rurik.mysql.com's avatar
      Fixed bug #21727. · 2a7acba7
      igor@rurik.mysql.com authored
      This is a performance issue for queries with subqueries evaluation
      of which requires filesort.
      Allocation of memory for the sort buffer at each evaluation of a
      subquery may take a significant amount of time if the buffer is rather big.
      With the fix we allocate the buffer at the first evaluation of the
      subquery and reuse it at each subsequent evaluation.
      2a7acba7
  7. 30 Oct, 2006 1 commit
  8. 17 Oct, 2006 1 commit
    • gkodinov/kgeorge@macbook.gmz's avatar
      Bug#21798: memory leak during query execution with subquery in column · f7b89376
      gkodinov/kgeorge@macbook.gmz authored
                  list using a function
      When executing dependent subqueries they are re-inited and re-exec() for 
      each row of the outer context.
      The cause for the bug is that during subquery reinitialization/re-execution,
      the optimizer reallocates JOIN::join_tab, JOIN::table in make_simple_join()
      and the local variable in 'sortorder' in create_sort_index(), which is
      allocated by make_unireg_sortorder().
      Care must be taken not to allocate anything into the thread's memory pool
      while re-initializing query plan structures between subquery re-executions.
      All such items mush be cached and reused because the thread's memory pool
      is freed at the end of the whole query.
      Note that they must be cached and reused even for queries that are not 
      otherwise cacheable because otherwise it will grow the thread's memory 
      pool every time a cacheable query is re-executed. 
      We provide additional members to the JOIN structure to store references 
      to the items that need to be cached.
      f7b89376
  9. 13 Oct, 2006 1 commit
    • evgen@moonbone.local's avatar
      Bug#14959: ALTER TABLE isn't able to rename a view · 2b474898
      evgen@moonbone.local authored
      The mysql_alter_table() was able to rename only a table.
      
      The view/table renaming code is moved from the function rename_tables 
      to the new function called do_rename().
      The mysql_alter_table() function calls it when it needs to rename a view.
      2b474898
  10. 03 Oct, 2006 1 commit
    • cmiller@zippy.cornsilk.net's avatar
      Bug #14262: SP: DROP PROCEDURE|VIEW (maybe more) write to binlog too late \ · 5512100c
      cmiller@zippy.cornsilk.net authored
      	(race cond)
      
      It was possible for one thread to interrupt a Data Definition Language 
      statement and thereby get messages to the binlog out of order.  Consider:
      
      Connection 1: Drop Foo x
      Connection 2: Create or replace Foo x
      Connection 2: Log "Create or replace Foo x"
      Connection 1: Log "Drop Foo x"
      
      Local end would have Foo x, but the replicated slaves would not.
      
      The fix for this is to wrap all DDL and logging of a kind in the same mutex.  
      Since we already use mutexes for the various parts of altering the server, 
      this only entails moving the logging events down close to the action, inside 
      the mutex protection.
      5512100c
  11. 29 Aug, 2006 1 commit
  12. 15 Aug, 2006 1 commit
  13. 27 Jul, 2006 1 commit
    • anozdrin/alik@booka.'s avatar
      Fix for BUG#16211: Stored function return type for strings is ignored. · b7f403b5
      anozdrin/alik@booka. authored
      Fix for BUG#16676: Database CHARSET not used for stored procedures
      
      The problem in BUG#16211 is that CHARSET-clause of the return type for
      stored functions is just ignored.
      
      The problem in BUG#16676 is that if character set is not explicitly
      specified for sp-variable, the server character set is used instead
      of the database one.
      
      The fix has two parts:
      
        - always store CHARSET-clause of the return type along with the
          type definition in mysql.proc.returns column. "Always" means that
          CHARSET-clause is appended even if it has not been explicitly
          specified in CREATE FUNCTION statement (this affects BUG#16211 only).
      
          Storing CHARSET-clause if it is not specified is essential to avoid
          changing character set if the database character set is altered in
          the future.
      
          NOTE: this change is not backward compatible with the previous releases.
      
        - use database default character set if CHARSET-clause is not explicitly
          specified (this affects both BUG#16211 and BUG#16676).
      
          NOTE: this also breaks backward compatibility.
      b7f403b5
  14. 10 Jul, 2006 1 commit
  15. 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
  16. 29 Jun, 2006 1 commit
  17. 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
  18. 23 Jun, 2006 1 commit
  19. 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
  20. 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
  21. 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
  22. 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
  23. 03 May, 2006 1 commit
  24. 28 Apr, 2006 1 commit
  25. 25 Apr, 2006 1 commit
  26. 12 Apr, 2006 1 commit
  27. 30 Mar, 2006 1 commit
  28. 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
  29. 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
  30. 24 Feb, 2006 1 commit
  31. 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
  32. 17 Feb, 2006 1 commit
  33. 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
  34. 13 Jan, 2006 1 commit