An error occurred fetching the project authors.
  1. 17 Jan, 2007 1 commit
  2. 15 Jan, 2007 1 commit
  3. 03 Jan, 2007 1 commit
    • malff/marcsql@weblab.(none)'s avatar
      Bug#25302 (893 reduce/reduce conflicts in parser grammar) · 4cae0119
      malff/marcsql@weblab.(none) authored
      This fix corrects build issues introduced by WL#3031:
      
      - In the SQL grammar, 'USER' is a SQL 2003 reserved keyword,
      and therefore should not be part of the keyword production.
      
      - In sql/sql_parse.cc, the code for CREATE SERVER and ALTER SERVER
      was not using proper format strings in the DBUG_PRINT statements.
      4cae0119
  4. 23 Dec, 2006 1 commit
  5. 11 Dec, 2006 1 commit
  6. 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
  7. 05 Dec, 2006 1 commit
  8. 04 Dec, 2006 1 commit
    • andrey@example.com's avatar
      Fix for bug#22369: Alter table rename combined · e6a47277
      andrey@example.com authored
      with other alterations causes lost tables
      
      Using RENAME clause combined with other clauses of ALTER TABLE led to
      data loss (the data was there but not accessible). This could happen if the
      changes do not change the table much. Adding and droppping of fields and
      indices was safe. Renaming a column with MODIFY or CHANGE was unsafe operation,
      if the actual column didn't change (changing from int to int, which is a noop)
        
      Depending on the storage engine (SE) the behavior is different:
      1)MyISAM/MEMORY - the ALTER TABLE statement completes
        without any error but next SELECT against the new table fails.
      2)InnoDB (and every other transactional table) - The ALTER TABLE statement
        fails. There are the the following files in the db dir -
        `new_table_name.frm` and a temporary table's frm. If the SE is file
        based, then the data and index files will be present but with the old
        names. What happens is that for InnoDB the table is not renamed in the
        internal DDIC.
      
      Fixed by adding additional call to mysql_rename_table() method, which should
      not include FRM file rename, because it has been already done during file
      names juggling.
      e6a47277
  9. 02 Dec, 2006 2 commits
  10. 01 Dec, 2006 2 commits
  11. 30 Nov, 2006 2 commits
    • msvensson@neptunus.(none)'s avatar
      b9d69609
    • monty@mysql.com/narttu.mysql.fi's avatar
      Fixed compiler warnings (Mostly VC++): · 3a35c300
      monty@mysql.com/narttu.mysql.fi authored
      - Removed not used variables
      - Changed some ulong parameters/variables to ulonglong (possible serious bug)
      - Added casts to get rid of safe assignment from longlong to long (and similar)
      - Added casts to function parameters
      - Fixed signed/unsigned compares
      - Added some constructores to structures
      - Removed some not portable constructs
      
      Better fix for bug Bug #21428 "skipped 9 bytes from file: socket (3)" on "mysqladmin shutdown"
      (Added new parameter to net_clear() to define when we want the communication buffer to be emptied)
      3a35c300
  12. 29 Nov, 2006 1 commit
    • monty@mysql.com/narttu.mysql.fi's avatar
      Added back sql-bench directory, so that one can more easily run benchmarks on... · 23263db6
      monty@mysql.com/narttu.mysql.fi authored
      Added back sql-bench directory, so that one can more easily run benchmarks on a server and add new benchmarks for new optimizations
      Fixed memory leak in _db_set() (Bug#24497 Valgrind warning: get_one_option)
      Don't call net_clear() on COM_QUIT. This avoids a warning from net_clear() after shutdown: "skipped ## bytes from file"
      BUG#21428: skipped 9 bytes from file: socket (3)" on "mysqladmin shutdown"
      23263db6
  13. 28 Nov, 2006 2 commits
  14. 26 Nov, 2006 1 commit
    • monty@mysql.com/nosik.monty.fi's avatar
      Fixed a LOT of compiler warnings · fa81a82e
      monty@mysql.com/nosik.monty.fi authored
      Added missing DBUG_RETURN statements (in mysqldump.c)
      Added missing enums
      Fixed a lot of wrong DBUG_PRINT() statements, some of which could cause crashes
      Removed usage of %lld and %p in printf strings as these are not portable or produces different results on different systems.
      fa81a82e
  15. 21 Nov, 2006 1 commit
  16. 20 Nov, 2006 2 commits
    • monty@mysql.com/nosik.monty.fi's avatar
      Remove compiler warnings · e8258798
      monty@mysql.com/nosik.monty.fi authored
      (Mostly in DBUG_PRINT() and unused arguments)
      Fixed bug in query cache when used with traceing (--with-debug)
      Fixed memory leak in mysqldump
      Removed warnings from mysqltest scripts (replaced -- with #)
      e8258798
    • kaa@polly.local's avatar
      Fix for bug #22077 "DROP TEMPORARY TABLE fails with wrong error if read_only is set" · 346033a5
      kaa@polly.local authored
      Do not issue a 'read-only' error in case of DROP TEMPORARY TABLE on a non-existing temporary table.
      Instead produce the correct "Unknown table" error or warning (in cases when the IF EXISTS clause was specified).
      
      To a documentor: the part of the manual describing the 'read_only' system variable should be clarified to state the following:
      "When the read_only variable is set to ON, all operations which create/update/drop tables are rejected with the exceptions for:
      1. Any operation performed by the replication thread on a slave server
      2. Any operation performed by a user that have the SUPER privilege
      3. Any operation that creates/updates/drops only temporary tables"
      346033a5
  17. 17 Nov, 2006 1 commit
  18. 15 Nov, 2006 1 commit
    • tnurnberg@salvation.intern.azundris.com's avatar
      Bug#16456 "RBR: rpl_sp.test expects query to fail, but passes in RBR" · ea3bf1b2
      calling (rather than defining) non-deterministic SP in SBR (as opposed
      to RBR or mixed) will throw an error now.
      
      require mixed mode for tests now. SBR will now fail when calling
      non-deter SPs and SFs (as it should), and RBR already failed by virtue of
      giving different results for "show binlog" than the results-file has.
      also test for 16456 now. lastly make amends because one of the tests
      fails with a new error # now as code was added to sql_trigger.cc while
      test was disabled.
      ea3bf1b2
  19. 14 Nov, 2006 2 commits
    • andrey@example.com's avatar
      Fix for bug#23760 ROW_COUNT() and store procedure not owrking together · 9299fd67
      andrey@example.com authored
      The problem was that THD::row_count_func was zeroed too. It was zeroed
      as a fix for bug 4905 "Stored procedure doesn't clear for "Rows affected"
      However, the proper solution is not to zero, because THD::row_count_func has
      been set to -1 already in mysql_execute_command(), a later fix, which obsoletes
      the incorrect fix of #4095
      9299fd67
    • evgen@moonbone.local's avatar
      Bug#20045: Server crash on INSERT ... SELECT ... FROM non-mergeable view · 51983545
      evgen@moonbone.local authored
      The regression is caused by the fix for bug 14767. When INSERT ... SELECT
      used a view in the SELECT list that was not inlined, and there was an 
      active transaction, the server could crash in Query_cache::invalidate.
      
      On INSERT ... SELECT only the table being inserted into is invalidated.
      Thus views that can't be inlined are skipped from invalidation.
      
      The bug manifests itself in two ways so there is 2 test cases.
      One checks that the only the table being inserted into is invalidated.
      And the second one checks that there is no crash on INSERT ... SELECT.
      51983545
  20. 02 Nov, 2006 1 commit
    • andrey@example.com's avatar
      Better fix for bug#22830 · c27a88ca
      andrey@example.com authored
      Events: crash with procedure which alters events with function
      
      Post-review CS
      
      This fix also changes the handling of KILL command combined with
      subquery. It changes the error message given back to "not supported",
      from parse error. The error for CREATE|ALTER EVENT has also been changed
      to generate "not supported yet" instead of parse error.
      In case of a SP call, the error is "not supported yet". This change
      cleans the parser from code which should not belong to there. Still
      LEX::expr_allows_subselect is existant because it simplifies the handling
       of SQLCOM_HA_READ which forbids subselects.
      c27a88ca
  21. 01 Nov, 2006 2 commits
  22. 30 Oct, 2006 2 commits
    • bar@mysql.com/bar.intranet.mysql.r18.ru's avatar
      Bug#20404: SHOW CREATE TABLE fails with Turkish I · d18fcb3a
        
        Problem: SHOW CREATE TABLE printed garbage in table
        name for tables having TURKISH I
        (i.e. LATIN CAPITABLE LETTER I WITH DOT ABOVE)
        when lower-case-table-name=1.
        
        Reason: In some cases during lower/upper conversion in utf8,
        the result string can be shorter the original string
        (including the above letter). Old implementation of caseup_str()
        and casedn_str() didn't handle the result length properly,
        assuming that length cannot change.
        
        This fix changes the result type of cs->cset->casedn_str()
        and cs->cset->caseup_str() from VOID to UINT, to return
        the result length, as well as put '\0' terminator on a 
        proper place.
        
        Also, my_caseup_str_utf8() and my_casedn_str_utf8() were 
        rewritten not to use strlen() for performance purposes.
        It was done with help of adding of new functions - my_utf8_uni_no_range()
        and my_uni_utf8_no_range() - for null terminated strings.
      d18fcb3a
    • kostja@bodhi.local's avatar
      A cleanup. · dfc4dd42
      kostja@bodhi.local authored
      dfc4dd42
  23. 27 Oct, 2006 1 commit
    • kroki/tomash@moonlight.intranet's avatar
      BUG#22584: last_insert_id not updated after inserting a record through · 0e0f7a04
      kroki/tomash@moonlight.intranet authored
      a updatable view.
      
      When there's a VIEW on a base table that have AUTO_INCREMENT column, and
      this VIEW doesn't provide an access such column, after INSERT to such
      VIEW LAST_INSERT_ID() did not return the value just generated.
      
      This behaviour is intended and correct, because if the VIEW doesn't list
      some columns then these columns are effectively hidden from the user,
      and so any side effects of inserting default values to them.
      
      However, there was a bug that such statement inserting into a view would
      reset LAST_INSERT_ID() instead of leaving it unchanged.
      
      This patch restores the original value of LAST_INSERT_ID() instead of
      resetting it to zero.
      0e0f7a04
  24. 26 Oct, 2006 1 commit
  25. 19 Oct, 2006 1 commit
    • kroki/tomash@moonlight.intranet's avatar
      BUG#21856: Prepared Statements: crash if bad create · 00b2fc6a
      kroki/tomash@moonlight.intranet authored
      When statement to be prepared contained CREATE PROCEDURE, CREATE FUNCTION
      or CREATE TRIGGER statements with a syntax error in it, the preparation
      would fail with syntax error message, but the memory could be corrupted.
      
      The problem occurred because we switch memroot when parse stored
      routine or trigger definitions, and on parse error we restored the
      original memroot only after performing some memory operations.  In more
      detail:
       - prepared statement would activate its own memory root to parse
         the definition of the stored procedure.
       - SP would reset this memory root with its own memory root to
         parse SP statements
       - a syntax error would happen
       - prepared statement would restore the original memory root
       - stored procedure would restore what it thinks was the original
         memory root, but actually was the statement memory root.
      That led to double free - in destruction of the statement and in
      a next call to mysql_parse().
      
      The solution is to restore memroot right after the failed parsing.
      00b2fc6a
  26. 17 Oct, 2006 1 commit
  27. 16 Oct, 2006 1 commit
  28. 12 Oct, 2006 2 commits
  29. 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