An error occurred fetching the project authors.
  1. 28 Nov, 2006 1 commit
  2. 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
  3. 21 Nov, 2006 2 commits
  4. 20 Nov, 2006 1 commit
    • 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
  5. 17 Nov, 2006 1 commit
  6. 01 Nov, 2006 2 commits
    • monty@mysql.com/nosik.monty.fi's avatar
      Fixed a lot of compiler warnings (Mainly in mysqld and instance manager) · ca99516c
      monty@mysql.com/nosik.monty.fi authored
      Fixed some possible fatal wrong arguments to printf() style functions
      Initialized some not initialized variables
      Fixed bug in stored procedure and continue handlers
      (Fixes Bug#22150)
      ca99516c
    • 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. 19 Oct, 2006 1 commit
    • ramil/ram@mysql.com/myoffice.izhnet.ru's avatar
      Fix for bug #20732: Partial index and long sjis search with '>' fails sometimes · 0027b6e4
      We miss some records sometimes using RANGE method if we have
      partial key segments.
      Example:
        Create table t1(a char(2), key(a(1)));
        insert into t1 values ('a'), ('xx');
        select a from t1 where a > 'x';
      We call index_read() passing 'x' key and HA_READ_AFTER_KEY flag
      in the handler::read_range_first() wich is wrong because we have
      a partial key segment for the field and might miss records like 'xx'.
      
      Fix: don't use open segments in such a case.
      0027b6e4
  8. 16 Oct, 2006 1 commit
  9. 13 Oct, 2006 2 commits
    • petr/cps@mysql.com/owlet.local's avatar
      Fix for Bug #17544 "Cannot do atomic log rotate", · 6846f8d9
      petr/cps@mysql.com/owlet.local authored
      Bug #21785 "Server crashes after rename of the log table" and
      Bug #21966 "Strange warnings on create like/repair of the log
                  tables"
      
      According to the patch, from now on, one should use RENAME to
      perform a log table rotation (this should also be reflected in
      the manual).
      
      Here is a sample:
      
      use mysql;
      CREATE TABLE IF NOT EXISTS general_log2 LIKE general_log;
      RENAME TABLE general_log TO general_log_backup, general_log2 TO general_log;
      
      The rules for Rename of the log tables are following:
            IF   1. Log tables are enabled
            AND  2. Rename operates on the log table and nothing is being
                    renamed to the log table.
            DO   3. Throw an error message.
            ELSE 4. Perform rename.
       
      The very RENAME query will go the the old (backup) table. This is
      consistent with the behavoiur we have with binlog ROTATE LOGS
      statement.
      
      Other problems, which are solved by the patch are:
      
      1) Now REPAIR of the log table is exclusive operation (as it should be), this
         also eliminates lock-related warnings. and
      2) CREATE LIKE TABLE now usese usual read lock on the source table rather
         then name lock, which is too restrictive. This way we get rid of another
         log table-related warning, which occured because of the above fact
         (as a side-effect, name lock resulted in a warning).
      6846f8d9
    • dli@dev3-76.dev.cn.tlan's avatar
      ndb - fixed for BUG#15021, binlog_index table become inconsistent if errors... · 01c02f34
      dli@dev3-76.dev.cn.tlan authored
      ndb - fixed for BUG#15021, binlog_index table become inconsistent if errors during purge of binlogs.
      if EMFILE error occured while purging binary logs, stop purging logs and report error message to user.
      01c02f34
  10. 29 Sep, 2006 1 commit
    • holyfoot/hf@mysql.com/deer.(none)'s avatar
      bug #16813 (WITH CHECK OPTION fails with UPDATE) · 3474fc9a
      holyfoot/hf@mysql.com/deer.(none) authored
      We use the condition from CHECK OPTION twice handling UPDATE command.
      First we construnct 'update_cond' AND 'option_cond'
      condition to select records to be updated, then we check the
      'option_cond' for the updated row.
      The problem is that first 'AND' condition is optimized during the 'select'
      which can break 'option_cond' structure, so it will be unusable for
      the sectond use - to check the updated row.
      Possible soultion is either use copy of the condition in the first
      use or to make optimization less traumatic for the operands.
      I picked the first one. 
      3474fc9a
  11. 28 Sep, 2006 1 commit
  12. 27 Sep, 2006 1 commit
  13. 19 Sep, 2006 1 commit
  14. 15 Sep, 2006 1 commit
  15. 11 Sep, 2006 1 commit
  16. 31 Aug, 2006 1 commit
  17. 30 Aug, 2006 1 commit
  18. 22 Aug, 2006 1 commit
  19. 21 Aug, 2006 1 commit
    • dlenev@mockturtle.local's avatar
      Fix for bug#19403/12212 "Crash that happens during removing of database name · 8fb55ff0
      dlenev@mockturtle.local authored
      from cache" and #21216 "Simultaneous DROP TABLE and SHOW OPEN TABLES causes
      server to crash".
      
      Crash happened when one ran DROP DATABASE or SHOW OPEN TABLES statements
      while concurrently doing DROP TABLE (or RENAME TABLE, CREATE TABLE LIKE
      or any other command that takes name-lock) in other connection.
      
      This problem was caused by the fact that table placeholders which were
      added to table cache in order to obtain name-lock on table had
      TABLE_SHARE::db and table_name set to 0. Therefore they broke assumption
      that these members are non-0 for all tables in table cache on which some
      of our code relies.
      
      The fix sets these members for such placeholders to appropriate value making
      this assumption true again. As attempt to avoid such problems in future
      we introduce auxiliary TABLE_SHARE::set_table_cache_key() methods which
      should be used when one wants to set TABLE_SHARE::table_cache_key and which
      ensure that TABLE_SHARE::table_name/db are set properly.
      
      Test cases for these bugs were added to 5.0 test-suite (with 5.0-specific
      fix for bug #21216).
      8fb55ff0
  20. 17 Aug, 2006 1 commit
  21. 16 Aug, 2006 1 commit
  22. 09 Aug, 2006 1 commit
  23. 08 Aug, 2006 1 commit
  24. 02 Aug, 2006 1 commit
    • ingo/istruewing@chilla.local's avatar
      Bug#18775 - Temporary table from alter table visible to other threads · 8e4c36ad
      ingo/istruewing@chilla.local authored
      Continued implementation of WL#1324 (table name to filename encoding)
      
      The intermediate (not temporary) files of the new table
      during ALTER TABLE was visible for SHOW TABLES. These
      intermediate files are copies of the original table with
      the changes done by ALTER TABLE. After all the data is
      copied over from the original table, these files are renamed 
      to the original tables file names. So they are not temporary 
      files. They persist after ALTER TABLE, but just with another 
      name.
      
      In 5.0 the intermediate files are invisible for SHOW TABLES
      because all file names beginning with "#sql" were suppressed.
      
      This failed since 5.1.6 because even temporary table names were
      converted when making file names from them. The prefix became
      converted to "@0023sql". Converting the prefix during SHOW TABLES
      would suppress the listing of user tables that start with "#sql".
      
      The solution of the problem is to continue the implementation of
      the table name to file name conversion feature. One requirement
      is to suppress the conversion for temporary table names.
      
      This change is straightforward for real temporary tables as there
      is a function that creates temporary file names.
      
      But the generated path names are located in TMPDIR and have no
      relation to the internal table name. This cannot be used for
      ALTER TABLE. Its intermediate files need to be in the same
      directory as the old table files. And it is necessary to be
      able to deduce the same path from the same table name repeatedly.
      
      Consequently the intermediate table files must be handled like normal
      tables. Their internal names shall start with tmp_file_prefix
      (#sql) and they shall not be converted like normal table names.
      
      I added a flags parameter to all relevant functions that are
      called from ALTER TABLE. It is used to suppress the conversion
      for the intermediate table files.
      
      The outcome is that the suppression of #sql in SHOW TABLES
      works again. It does not suppress user tables as these are
      converted to @0023sql on file level.
      
      This patch does also fix ALTER TABLE ... RENAME, which could not 
      rename a table with non-ASCII characters in its name.
      
      It does also fix the problem that a user could create a table like
      `#sql-xxxx-yyyy`, where xxxx is mysqld's pid and yyyy is the thread
      ID of some other thread, which prevented this thread from running 
      ALTER TABLE.
      
      Some of the above problems are mentioned in Bug 1405, which can
      be closed with this patch.
      
      This patch does also contain some minor fixes for other forgotten
      conversions. Still known problems are reported as bugs 21370,
      21373, and 21387.
      8e4c36ad
  25. 14 Jul, 2006 1 commit
  26. 11 Jul, 2006 1 commit
  27. 06 Jul, 2006 3 commits
    • konstantin@bodhi.netgear's avatar
      A fix and a test case for Bug#19399 "res 'Lost Connection' when · 8e735d2c
      konstantin@bodhi.netgear authored
      dropping/creating tables".
      
      The bug could lead to a crash when multi-delete statements were
      prepared and used with temporary tables.
      
      The bug was caused by lack of clean-up of multi-delete tables before
      re-execution of a prepared statement. In a statement like
      DELETE t1 FROM t1, t2 WHERE ... the first table list (t1) is
      moved to lex->auxilliary_table_list and excluded from lex->query_tables
      or select_lex->tables. Thus it was unaccessible to reinit_stmt_before_use
      and not cleaned up before re-execution of a prepared statement. 
      8e735d2c
    • ingo@chilla.local's avatar
      After merge fix. · 8ef49706
      ingo@chilla.local authored
      8ef49706
    • dlenev@mysql.com's avatar
      After merge fixes for patch solving bug#18437 "Wrong values inserted with a · d6f47c31
      dlenev@mysql.com authored
      before update trigger on NDB table".
      
      Two main changes:
      - We use TABLE::read_set/write_set bitmaps for marking fields used by
        statement instead of Field::query_id in 5.1.
      - Now when we mark columns used by statement we take into account columns 
        used by table's triggers instead of marking all columns as used if table
        has triggers.
      d6f47c31
  28. 30 Jun, 2006 3 commits
  29. 29 Jun, 2006 1 commit
  30. 26 Jun, 2006 1 commit
    • ingo@mysql.com's avatar
      Bug#16218 - Crash on insert delayed · 8728fbbc
      ingo@mysql.com 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.
      8728fbbc
  31. 25 Jun, 2006 1 commit
  32. 23 Jun, 2006 2 commits