An error occurred fetching the project authors.
  1. 14 Aug, 2006 1 commit
  2. 08 Aug, 2006 1 commit
  3. 31 Jul, 2006 1 commit
  4. 27 Jul, 2006 1 commit
    • anozdrin/alik@booka.'s avatar
      Fix for BUG#20438: CREATE statements for views, stored routines and triggers · 2d082d86
      anozdrin/alik@booka. authored
      can be not replicable.
      
      Now CREATE statements for writing in the binlog are created as follows:
        - the beginning of the statement is re-created;
        - the rest of the statement is copied from the original query.
      
      The problem appears when there is a version-specific comment (produced by
      mysqldump), started in the re-created part of the statement and closed in the
      copied part -- there is closing comment-parenthesis, but there is no opening
      one.
      
      The proper fix could be to re-create original statement, but we can not
      implement it in 5.0. So, for 5.0 the fix is just to cut closing
      comment-parenthesis. This technique is also used for SHOW CREATE PROCEDURE
      statement (so we are able to reuse existing code).
      2d082d86
  5. 09 Jul, 2006 1 commit
    • guilhem@gbichot3.local's avatar
      * Mixed replication mode * : · fdb0f85a
      guilhem@gbichot3.local authored
      1) Fix for BUG#19630 "stored function inserting into two auto_increment breaks
      statement-based binlog":
      a stored function inserting into two such tables may fail to replicate
      (inserting wrong data in the slave's copy of the second table) if the slave's
      second table had an internal auto_increment counter different from master's.
      Because the auto_increment value autogenerated by master for the 2nd table
      does not go into binlog, only the first does, so the slave lacks information.
      To fix this, if running in mixed binlogging mode, if the stored function or
      trigger plans to update two different tables both having auto_increment
      columns, we switch to row-based for the whole function.
      We don't have a simple solution for statement-based binlogging mode, there
      the bug remains and will be documented as a known problem.
      Re-enabling rpl_switch_stm_row_mixed.
      2) Fix for BUG#20630 "Mixed binlogging mode does not work with stored
      functions, triggers, views", which was a documented limitation (in mixed
      mode, we didn't detect that a stored function's execution needed row-based
      binlogging (due to some UUID() call for example); same for
      triggers, same for views (a view created from a SELECT UUID(), and doing
      INSERT INTO sometable SELECT theview; would not replicate row-based).
      This is implemented by, after parsing a routine's body, remembering in sp_head
      that this routine needs row-based binlogging. Then when this routine is used,
      the caller is marked to require row-based binlogging too.
      Same for views: when we parse a view and detect that its SELECT needs
      row-based binary logging, we mark the calling LEX as such.
      3) Fix for BUG#20499 "mixed mode with temporary table breaks binlog":
      a temporary table containing e.g. UUID has its changes not binlogged,
      so any query updating a permanent table with data from the temporary table
      will run wrongly on slave. Solution: in mixed mode we don't switch back
      from row-based to statement-based when there exists temporary tables.
      4) Attempt to test mysqlbinlog on a binlog generated by mysqlbinlog;
      impossible due to BUG#11312 and BUG#20329, but test is in place for when
      they are fixed.
      fdb0f85a
  6. 03 Jul, 2006 1 commit
  7. 30 Jun, 2006 1 commit
  8. 28 Jun, 2006 1 commit
    • andrey@lmy004.'s avatar
      WL#3337 (Events new architecture) · 3c793e23
      andrey@lmy004. authored
      This cut No 7 should finish the part of fixing the parsing of the events :
      - Event_timed is no more used during parsing. Less problems because it has
        a mutex. Event_parse_data class is used during parsing. It is suited only
        for this purpose. It's pretty lightweight
      - Late checking of data from parsing is being performed. This should solve
        the problems of nested events in SP or other events (for the situation 
        of no nested bodies). Before if an ALTER EVENT was in a SP, then when the
        SP was compiled, and not executed, the actual init_xxx methods of Event_timed
        were called, which is wrong.
      - It could be a side effect of using a specialized class, but test events_stress is
        now 25% quicker.
      
      Cut No8 will start splitting Event_scheduler into 2 parts, the QUEUE will be moved
      to Event_queue.
      3c793e23
  9. 27 Jun, 2006 2 commits
  10. 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
  11. 20 Jun, 2006 1 commit
    • monty@mysql.com's avatar
      SHOW STATUS does not anymore change local status variables (except... · be269e56
      monty@mysql.com authored
      SHOW STATUS does not anymore change local status variables (except com_show_status). Global status variables are still updated.
      SHOW STATUS are not anymore put in slow query log because of no index usage.
      
      Implemntation done by removing orig_sql_command and moving logic of SHOW STATUS to mysql_excute_command()
      This simplifies code and allows us to remove some if statements all over the code.
      
      Upgraded uc_update_queries[] to sql_command_flags and added more bitmaps to better categorize commands.
      This allowed some overall simplifaction when testing sql_command.
      
      Fixes bugs:
      Bug#10210: running SHOW STATUS increments counters it shouldn't
      Bug#19764: SHOW commands end up in the slow log as table scans
      be269e56
  12. 07 Jun, 2006 1 commit
    • evgen@moonbone.local's avatar
      Fixed bug#19789: REPLACE was allowed for a VIEW with CHECK OPTION enabled. · 97436287
      evgen@moonbone.local authored
      The st_lex::which_check_option_applicable() function controls for which 
      statements WITH CHECK OPTION clause should be taken into account. REPLACE and
      REPLACE_SELECT wasn't in the list which results in allowing REPLACE to insert
      wrong rows in a such view.
      
      The st_lex::which_check_option_applicable() now includes REPLACE and 
      REPLACE_SELECT in the list of statements for which WITH CHECK OPTION clause is
      applicable.
      97436287
  13. 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
  14. 22 May, 2006 1 commit
    • andrey@lmy004.'s avatar
      fix for bug #17619 Scheduler race conditions · b429d73d
      andrey@lmy004. authored
      - Scheduler is either initialized at server start or never.
        Starting & stopping is now suspending & resuming.
      - The scheduler has clear OO interface
      - Now all calls to the scheduler are synchronous
      - GLOBAL event_scheduler uses thd::sys_var_tmp (see set_var.cc)
      - External API is encapsulated into class Events
      - Includes fixes for all comments of Kostja's review of 19.05.2005
      
      Starting to merge into 5.1-release (5.1.10) and push
      b429d73d
  15. 07 May, 2006 1 commit
    • igor@rurik.mysql.com's avatar
      Fixed bug #14927. · 7977a0c8
      igor@rurik.mysql.com authored
      A query with a group by and having clauses could return a wrong
      result set if the having condition contained a constant conjunct 
      evaluated to FALSE.
      It happened because the pushdown condition for table with
      grouping columns lost its constant conjuncts.
      Pushdown conditions are always built by the function make_cond_for_table
      that ignores constant conjuncts. This is apparently not correct when
      constant false conjuncts are present.
      7977a0c8
  16. 03 May, 2006 3 commits
  17. 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
  18. 30 Mar, 2006 1 commit
    • ingo@mysql.com's avatar
      Bug#18477 - MySQL/InnoDB Ignoring Foreign Keys in ALTER TABLE · 7253099c
      ingo@mysql.com authored
      InnoDB requires a full table rebuild for foreign key changes.
      It was not possible in compare_tables() to detect such changes.
      
      On Heikkis proposal I added a new flag to the syntax parser
      where foreign key definition changes are done. I test for
      this flag in compare_tables() now.
      7253099c
  19. 20 Mar, 2006 1 commit
  20. 16 Mar, 2006 2 commits
  21. 13 Mar, 2006 1 commit
  22. 10 Mar, 2006 1 commit
  23. 09 Mar, 2006 1 commit
  24. 02 Mar, 2006 1 commit
    • anozdrin@mysql.com's avatar
      Implementation of WL#2897: Complete definer support in the stored routines. · fbb59203
      anozdrin@mysql.com authored
      The idea is to add DEFINER-clause in CREATE PROCEDURE and CREATE FUNCTION
      statements. Almost all support of definer in stored routines had been already
      done before this patch.
      
      NOTE: this patch changes behaviour of dumping stored routines in mysqldump.
      Before this patch, mysqldump did not dump DEFINER-clause for stored routines
      and this was documented behaviour. In order to get full information about stored
      routines, one should have dumped mysql.proc table. This patch changes this
      behaviour, so that DEFINER-clause is dumped.
      
      Since DEFINER-clause is not supported in CREATE PROCEDURE | FUNCTION statements
      before this patch, the clause is covered by additional version-specific comments.
      fbb59203
  25. 28 Feb, 2006 1 commit
  26. 13 Feb, 2006 1 commit
  27. 01 Feb, 2006 1 commit
    • igor@rurik.mysql.com's avatar
      FIxed bug #14927. · d6370b48
      igor@rurik.mysql.com authored
      A query with a group by and having clauses could return a wrong
      result set if the having condition contained a constant conjunct 
      evaluated to FALSE.
      It happened because the pushdown condition for table with
      grouping columns lost its constant conjuncts.
      Pushdown conditions are always built by the function make_cond_for_table
      that ignores constant conjuncts. This is apparently not correct when
      constant false conjuncts are present.
      d6370b48
  28. 30 Jan, 2006 1 commit
    • andrey@lmy004.'s avatar
      fix for bug#16642 (Events: No INFORMATION_SCHEMA.EVENTS table) · d847ac54
      andrey@lmy004. authored
      post-review change - use pointer instead of copy on the stack.
      WL#1034 (Internal CRON)
       This patch adds INFORMATION_SCHEMA.EVENTS table with the following format:
        EVENT_CATALOG  - MYSQL_TYPE_STRING  (Always NULL)
        EVENT_SCHEMA   - MYSQL_TYPE_STRING  (the database)
        EVENT_NAME     - MYSQL_TYPE_STRING  (the name)
        DEFINER        - MYSQL_TYPE_STRING  (user@host)
        EVENT_BODY     - MYSQL_TYPE_STRING  (the body from mysql.event)
        EVENT_TYPE     - MYSQL_TYPE_STRING  ("ONE TIME" | "RECURRING")
        EXECUTE_AT     - MYSQL_TYPE_TIMESTAMP (set for "ONE TIME" otherwise NULL)
        INTERVAL_VALUE - MYSQL_TYPE_LONG    (set for RECURRING otherwise NULL)
        INTERVAL_FIELD - MYSQL_TYPE_STRING  (set for RECURRING otherwise NULL)
        SQL_MODE       - MYSQL_TYPE_STRING  (for now NULL)
        STARTS         - MYSQL_TYPE_TIMESTAMP (starts from mysql.event)
        ENDS           - MYSQL_TYPE_TIMESTAMP (ends from mysql.event)
        STATUS         - MYSQL_TYPE_STRING  (ENABLED | DISABLED)
        ON_COMPLETION  - MYSQL_TYPE_STRING  (NOT PRESERVE | PRESERVE)
        CREATED        - MYSQL_TYPE_TIMESTAMP
        LAST_ALTERED   - MYSQL_TYPE_TIMESTAMP
        LAST_EXECUTED  - MYSQL_TYPE_TIMESTAMP
        EVENT_COMMENT  - MYSQL_TYPE_STRING
      
        SQL_MODE is NULL for now, because the value is still not stored in mysql.event .
      Support will be added as a fix for another bug.
      
       This patch also adds SHOW [FULL] EVENTS [FROM db] [LIKE pattern]
      1. SHOW EVENTS shows always only the events on the same user,
         because the PK of mysql.event is (definer, db, name) several 
         users may have event with the same name -> no information disclosure.
      2. SHOW FULL EVENTS - shows the events (in the current db as SHOW EVENTS)
         of all users. The user has to have PROCESS privilege, if not then
         SHOW FULL EVENTS behave like SHOW EVENTS.
      3. If [FROM db] is specified then this db is considered.
      4. Event names can be filtered with LIKE pattern.
        SHOW EVENTS returns table with the following columns, which are subset of
        the data which is returned by SELECT * FROM I_S.EVENTS
         Db
         Name
         Definer 
         Type
         Execute at
         Interval value
         Interval field 
         Starts 
         Ends
         Status
      d847ac54
  29. 19 Jan, 2006 1 commit
  30. 17 Jan, 2006 1 commit
  31. 11 Jan, 2006 1 commit
  32. 27 Dec, 2005 1 commit
  33. 22 Dec, 2005 2 commits
  34. 21 Dec, 2005 1 commit
  35. 02 Dec, 2005 1 commit