An error occurred fetching the project authors.
  1. 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
  2. 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
  3. 28 Jun, 2006 1 commit
    • konstantin@mysql.com's avatar
      A fix for Bug#19022 "Memory bug when switching db during trigger execution". · 55d148c5
      konstantin@mysql.com authored
      No test case as the bug is in an existing test case (rpl_trigger.test
      when it is run under valgrind).
      The warning was caused by memory corruption in replication slave: thd->db
      was pointing at a stack address that was previously used by 
      sp_head::execute()::old_db. This happened because mysql_change_db
      behaved differently in replication slave and did not make a copy of the 
      argument to assign to thd->db. 
      The solution is to always free the old value of thd->db and allocate a new
      copy, regardless whether we're running in a replication slave or not.
      55d148c5
  4. 26 Jun, 2006 1 commit
    • 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
  5. 29 May, 2006 1 commit
    • ingo@mysql.com's avatar
      Bug#19815 - CREATE/RENAME/DROP DATABASE can deadlock on a global read lock · d00441e3
      ingo@mysql.com authored
      The order of acquiring LOCK_mysql_create_db
      and wait_if_global_read_lock() was wrong. It could happen
      that a thread held LOCK_mysql_create_db while waiting for
      the global read lock to be released. The thread with the
      global read lock could try to administrate a database too.
      It would first try to lock LOCK_mysql_create_db and hang...
      
      The check if the current thread has the global read lock
      is done in wait_if_global_read_lock(), which could not be
      reached because of the hang in LOCK_mysql_create_db.
      
      Now I exchanged the order of acquiring LOCK_mysql_create_db
      and wait_if_global_read_lock(). This makes 
      wait_if_global_read_lock() fail with an error message for
      the thread with the global read lock. No deadlock happens.
      d00441e3
  6. 01 Mar, 2006 1 commit
  7. 25 Feb, 2006 3 commits
  8. 31 Jan, 2006 1 commit
  9. 03 Jan, 2006 1 commit
  10. 11 Dec, 2005 1 commit
  11. 11 Nov, 2005 1 commit
    • SergeyV@selena.'s avatar
      Fixes bug #14569. When no db is selected as current and we do create procedure db.sp()... · dbb29d11
      SergeyV@selena. authored
      we changing current db temporarily and restore it when sp is created. however thd->db
      in this case becomes empty string rather than NULL and so all checks of thd->db == NULL 
      will be false. So if after this we'll issue create procedure sp2()... without specifying
      db it will succeed and create sp with db=NULL, which causes mysqldto crash on 
      show procedure status statement.
      
      This patch fixes the problem.
      dbb29d11
  12. 21 Sep, 2005 1 commit
    • msvensson@neptunus.(none)'s avatar
      Bug #13231 mysqltest: fails to dectect when mysql_next_result fails · 0581a7f2
      msvensson@neptunus.(none) authored
       - Added functionality to check errors returned from mysql_next_result
       - Exit from mysqltest when and unexpected error occurs.
       - The above fixes reveal problems with rpl000009, sp-error and query_cache-
       - Fix sp-error by adding an expected error
       - Fix rpl000009 by not sending "ok" from mysql_create_db when called with silent flag from load_master_data
       - Fix query_cache in separate patch
      0581a7f2
  13. 20 Sep, 2005 1 commit
  14. 15 Sep, 2005 1 commit
  15. 12 Sep, 2005 1 commit
  16. 26 Aug, 2005 1 commit
  17. 25 Aug, 2005 1 commit
  18. 24 Aug, 2005 1 commit
  19. 22 Aug, 2005 1 commit
  20. 20 Aug, 2005 1 commit
  21. 19 Aug, 2005 1 commit
    • sasha@asksasha.com's avatar
      updated patch for BUG#4680 (incomplete DROP DATABASE breaking replication). · c594ab79
      sasha@asksasha.com authored
      We binlog the DROP TABLE for each table that was actually dropped. Per Sergei's 
      suggestion a fixed buffer for the DROP TABLE query is pre-allocated from THD pool, and 
      logging now is done in batches - new batch is started if the buffer becomes full.
      Reduced memory usage by reusing the table list instead of accumulating a list of 
      dropped table names. Also fixed the problem if the table was not actually dropped, eg
      due to permissions. Extended the test case to make sure batched query 
      logging does work.  
      c594ab79
  22. 12 Aug, 2005 1 commit
  23. 04 Aug, 2005 1 commit
  24. 20 May, 2005 1 commit
    • reggie@mdk10.(none)'s avatar
      BUG# 9148: Denial of service · 48c58453
      reggie@mdk10.(none) authored
      The problem was that on Windows the access method indicates that access to file 
      such as "com1" and "lpt1" is allowed (since they are device names) and
      this causes mysql to attempt to open them as databases or tables.
      
      The fix was to write our own my_access method that uses other Win32 functions
      to determine if the given argument is indeed a file and has to requested
      mode.
      48c58453
  25. 14 Apr, 2005 1 commit
  26. 19 Mar, 2005 1 commit
  27. 25 Feb, 2005 1 commit
  28. 22 Feb, 2005 1 commit
  29. 21 Feb, 2005 1 commit
  30. 02 Feb, 2005 1 commit
  31. 24 Jan, 2005 1 commit
  32. 06 Jan, 2005 1 commit
    • monty@mysql.com's avatar
      First stage of table definition cache · d35140a8
      monty@mysql.com authored
      Split TABLE to TABLE and TABLE_SHARE (TABLE_SHARE is still allocated as part of table, will be fixed soon)
      Created Field::make_field() and made Field_num::make_field() to call this
      Added 'TABLE_SHARE->db' that points to database name; Changed all usage of table_cache_key as database name to use this instead
      Changed field->table_name to point to pointer to alias. This allows us to change alias for a table by just updating one pointer.
      Renamed TABLE_SHARE->real_name to table_name
      Renamed TABLE->table_name to alias
      Renamed TABLE_LIST->real_name to table_name
      d35140a8
  33. 10 Dec, 2004 1 commit
  34. 09 Dec, 2004 2 commits
  35. 03 Dec, 2004 1 commit
    • mats@mysql.com's avatar
      Bug#6391 (binlog-do-db rules ignored) · 2bbdf240
      mats@mysql.com authored
        CREATE DATABASE statement used the current database instead of the
        database created when checking conditions for replication.
        CREATE/DROP/ALTER DATABASE statements are now replicated based on
        the manipulated database.
      2bbdf240
  36. 13 Nov, 2004 1 commit
  37. 12 Nov, 2004 1 commit