An error occurred fetching the project authors.
  1. 17 Apr, 2007 1 commit
  2. 13 Mar, 2007 1 commit
    • svoj@mysql.com/april.(none)'s avatar
      BUG#26881 - Large MERGE tables report incorrect specification when no · cb132bea
      svoj@mysql.com/april.(none) authored
                  differences in tables
      Certain merge tables were wrongly reported as having incorrect definition:
      - Some fields that are 1 byte long (e.g. TINYINT, CHAR(1)), might
        be internally casted (in certain cases) to a different type on a
        storage engine layer. (affects 4.1 and up)
      - If tables in a merge (and a MERGE table itself) had short VARCHAR column (less
        than 4 bytes) and at least one (but not all) tables were ALTER'ed (even to an
        identical table: ALTER TABLE xxx ENGINE=yyy), table definitions went ouf of
        sync. (affects 4.1 only)
      
      This is fixed by relaxing a check for underlying conformance and setting
      field type to FIELD_TYPE_STRING in case varchar is shorter than 4
      when a table is created.
      cb132bea
  3. 19 Feb, 2007 1 commit
  4. 29 Jan, 2007 1 commit
  5. 17 Jan, 2007 1 commit
  6. 15 Jan, 2007 1 commit
  7. 07 Dec, 2006 3 commits
    • 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
    • Kristofer.Pettersson@naruto.'s avatar
      Bug#17498 failed to put data file in custom directory use "data directory" option · ecbb4eb9
      Kristofer.Pettersson@naruto. authored
      - Using DATA/INDEX DIRECTORY option on Windows put data/index file into
        default directory because the OS doesn't support readlink().
      - The procedure for changing data/index file directory is 
        different under Windows.
      - With this fix we report a warning if DATA/INDEX option is used,
        but OS doesn't support readlink().
      ecbb4eb9
    • svoj@mysql.com/april.(none)'s avatar
      BUG#23404 - ROW_FORMAT=FIXED option is lost is an index is added to the · e17d7bce
      svoj@mysql.com/april.(none) authored
                  table
      
      ROW_FORMAT option is lost during CREATE/DROP INDEX.
      
      This fix forces CREATE/DROP INDEX to retain ROW_FORMAT by instructing
      mysql_alter_table() that ROW_FORMAT is not used during creating/dropping
      indexes.
      e17d7bce
  8. 05 Dec, 2006 1 commit
  9. 06 Oct, 2006 1 commit
    • kroki/tomash@moonlight.intranet's avatar
      BUG#21726: Incorrect result with multiple invocations of LAST_INSERT_ID. · ee0cebf9
      kroki/tomash@moonlight.intranet authored
      Note: bug#21726 does not directly apply to 4.1, as it doesn't have stored
      procedures.  However, 4.1 had some bugs that were fixed in 5.0 by the
      patch for bug#21726, and this patch is a backport of those fixes.
      Namely, in 4.1 it fixes:
      
        - LAST_INSERT_ID(expr) didn't return value of expr (4.1 specific).
      
        - LAST_INSERT_ID() could return the value generated by current
          statement if the call happens after the generation, like in
      
            CREATE TABLE t1 (i INT AUTO_INCREMENT PRIMARY KEY, j INT);
            INSERT INTO t1 VALUES (NULL, 0), (NULL, LAST_INSERT_ID());
      
        - Redundant binary log LAST_INSERT_ID_EVENTs could be generated.
      ee0cebf9
  10. 27 Sep, 2006 1 commit
  11. 04 Sep, 2006 1 commit
    • gkodinov/kgeorge@macbook.gmz's avatar
      Bug #21392: multi-table delete with alias table name fails with · 3758b975
      gkodinov/kgeorge@macbook.gmz authored
                  1003: Incorrect table name
      in multi-table DELETE the set of tables to delete from actually 
      references then tables in the other list, e.g:
      DELETE alias_of_t1 FROM t1 alias_of_t1 WHERE ....
      is a valid statement.
      So we must turn off table name syntactical validity check for alias_of_t1 
      because it's not a table name (even if it looks like one).
      In order to do that we add a special flag (TL_OPTION_ALIAS) to 
      disable the name checking for the aliases in multi-table DELETE.
      3758b975
  12. 30 Aug, 2006 1 commit
  13. 20 Jul, 2006 1 commit
  14. 27 Jun, 2006 1 commit
  15. 19 Jun, 2006 1 commit
    • holyfoot@deer.(none)'s avatar
      bug #20318 (ctype_ucs2_def test fails with embedded) · d8d42948
      holyfoot@deer.(none) authored
      there was two problems about charsets in embedded server
      1. mysys/charset.c - defined there default_charset_info variable is
      modified by both server and client code (particularly when
      --default-charset option is handled)
      In embedded server we get two codelines modifying one variable.
      I created separate default_client_charset_info for client code
      
      2. mysql->charset and mysql->options.charset initialization isn't
      properly done for embedded server - necessary calls added
      d8d42948
  16. 01 Jun, 2006 1 commit
    • holyfoot@deer.(none)'s avatar
      bug #16017 (memory leaks in embedded server) · bc35c500
      holyfoot@deer.(none) authored
      There actually was 3 different problems -
      hash_user_connections wasn't cleaned
      one strdupped database name wasn't freed
      and stmt->mem_root wasn't cleaned as it was
      replased with mysql->field_alloc for result
      For the last one - i made the library using stmt's
      fields to store result if it's the case.
      bc35c500
  17. 28 May, 2006 1 commit
    • evgen@moonbone.local's avatar
      Fixed bug#19225: unchecked error results in server crash · 1f30bf5a
      evgen@moonbone.local authored
      In multi-table delete a table for delete can't be used for selecting in
      subselects. Appropriate error was raised but wasn't checked which leads to a
      crash at the execution phase.
      
      The mysql_execute_command() now checks for errors before executing select
      for multi-delete.
      1f30bf5a
  18. 26 Apr, 2006 1 commit
  19. 25 Apr, 2006 2 commits
  20. 21 Apr, 2006 1 commit
    • igor@rurik.mysql.com's avatar
      Fixed bug #18767. · fc751415
      igor@rurik.mysql.com authored
      The bug caused wrong result sets for union constructs of the form
      (SELECT ... ORDER BY order_list1 [LIMIT n]) ORDER BY order_list2.
      For such queries order lists were concatenated and limit clause was
      completely neglected. 
      fc751415
  21. 21 Feb, 2006 1 commit
  22. 26 Jan, 2006 1 commit
  23. 07 Dec, 2005 1 commit
    • ingo@mysql.com's avatar
      BUG#5390 - problems with merge tables · 5aa315e2
      ingo@mysql.com authored
      Problem #1: INSERT...SELECT, Version for 4.1.
      INSERT ... SELECT with the same table on both sides (hidden
      below a MERGE table) does now work by buffering the select result.
      The duplicate detection works now after open_and_lock_tables() 
      on the locks.
      I did not find a test case that failed without the change in
      sql_update.cc. I made the change anyway as it should in theory
      fix a possible MERGE table problem with multi-table update.
      5aa315e2
  24. 04 Dec, 2005 1 commit
  25. 29 Nov, 2005 1 commit
    • ingo@mysql.com's avatar
      BUG#5390 - problems with merge tables · 76861ac6
      ingo@mysql.com authored
      Problem #1: INSERT...SELECT
      INSERT ... SELECT with the same table on both sides (hidden
      below a MERGE table) does now work by buffering the select result.
      The duplicate detection works now after open_and_lock_tables() 
      on the locks.
      I did not find a test case that failed without the change in
      sql_update.cc. I made the change anyway as it should in theory
      fix a possible MERGE table problem with multi-table update.
      76861ac6
  26. 10 Oct, 2005 2 commits
  27. 08 Oct, 2005 1 commit
  28. 19 Sep, 2005 1 commit
  29. 14 Sep, 2005 1 commit
  30. 10 Sep, 2005 1 commit
  31. 05 Sep, 2005 1 commit
  32. 03 Sep, 2005 1 commit
  33. 01 Sep, 2005 2 commits
  34. 31 Aug, 2005 2 commits
    • lars@mysql.com's avatar
      BUG#12542: All set statements should be executed by slave thd · 7fd89c85
      lars@mysql.com authored
      rpl_replicate_do.result:
        New test case
      sql_parse.cc:
        All SET statements should be executed by slave thd
      rpl_replicate_do.test:
        New test case
      7fd89c85
    • bar@mysql.com's avatar
      · f2ea1ac8
      bar@mysql.com authored
        bug#9948 changed client-charset behavior in 4.1.x libmysql, which issue BC prob
      
      sql_parse.cc:
      mysqld.cc:
      
        Added --skip-client-character-set-handshake.
        When this option is activated, client side character set
        (which is sent in handshake) is ignored, and server side
        default-character-set value is used for character_set_client
        and character_set_results, thus reprodicing 4.0 behaviour.
      f2ea1ac8