An error occurred fetching the project authors.
  1. 30 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. 13 Nov, 2006 1 commit
    • malff/marcsql@weblab.(none)'s avatar
      Bug#23703 (DROP TRIGGER needs an IF EXISTS) · 429b0e6c
      malff/marcsql@weblab.(none) authored
      This change set implements the DROP TRIGGER IF EXISTS functionality.
      
      This fix is considered a bug and not a feature, because without it,
      there is no known method to write a database creation script that can create
      a trigger without failing, when executed on a database that may or may not
      contain already a trigger of the same name.
      
      Implementing this functionality closes an orthogonality gap between triggers
      and stored procedures / stored functions (which do support the DROP IF
      EXISTS syntax).
      
      In sql_trigger.cc, in mysql_create_or_drop_trigger,
      the code has been reordered to:
      - perform the tests that do not depend on the file system (access()),
      - get the locks (wait_if_global_read_lock, LOCK_open)
      - call access()
      - perform the operation
      - write to the binlog
      - unlock (LOCK_open, start_waiting_global_read_lock)
      
      This is to ensure that all the code that depends on the presence of the
      trigger file is executed in the same critical section,
      and prevents race conditions similar to the case fixed by Bug 14262 :
      
      - thread 1 executes DROP TRIGGER IF EXISTS, access() returns a failure
      - thread 2 executes CREATE TRIGGER
      - thread 2 logs CREATE TRIGGER
      - thread 1 logs DROP TRIGGER IF EXISTS
      
      The patch itself is based on code contributed by the MySQL community,
      under the terms of the Contributor License Agreement (See Bug 18161).
      429b0e6c
  4. 21 Oct, 2006 1 commit
  5. 20 Oct, 2006 2 commits
    • cmiller@zippy.cornsilk.net's avatar
      Fix bad merge from #14262. · c2119709
      cmiller@zippy.cornsilk.net authored
      c2119709
    • dlenev@mockturtle.local's avatar
      Fix for bug#15228 "'invalid access to non-static data member' · 3fce634f
      dlenev@mockturtle.local authored
      warnings in sql_trigger.cc and sql_view.cc".
      
      According to the current version of C++ standard offsetof() macro
      can't be used for non-POD types. So warnings were emitted when we
      tried to use this macro for TABLE_LIST and Table_triggers_list
      classes. Note that despite of these warnings it was probably safe
      thing to do.
      
      This fix tries to circumvent this limitation by implementing
      custom version of offsetof() macro to be used with these
      classes. This hack should go away once we will refactor
      File_parser class.
      
      Alternative approaches such as disabling this warning for
      sql_trigger.cc/sql_view.cc or for the whole server were
      considered less explicit. Also I was unable to find a way
      to disable particular warning for particular _part_ of
      file in GCC.
      3fce634f
  6. 12 Oct, 2006 1 commit
  7. 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
  8. 30 Sep, 2006 1 commit
  9. 21 Sep, 2006 1 commit
    • dlenev@mockturtle.local's avatar
      Fix for bug#20670 "UPDATE using key and invoking trigger that modifies · 091ed9fb
      dlenev@mockturtle.local authored
      this key does not stop" (version for 5.0 only).
      
      UPDATE statement which WHERE clause used key and which invoked trigger
      that modified field in this key worked indefinetely.
      
      This problem occured because in cases when UPDATE statement was
      executed in update-on-the-fly mode (in which row is updated right
      during evaluation of select for WHERE clause) the new version of
      the row became visible to select representing WHERE clause and was
      updated again and again.
      We already solve this problem for UPDATE statements which does not
      invoke triggers by detecting the fact that we are going to update
      field in key used for scanning and performing update in two steps,
      during the first step we gather information about the rows to be
      updated and then doing actual updates. We also do this for
      MULTI-UPDATE and in its case we even detect situation when such
      fields are updated in triggers (actually we simply assume that
      we always update fields used in key if we have before update
      trigger).
      
      The fix simply extends this check which is done in check_if_key_used()/
      QUICK_SELECT_I::check_if_keys_used() routine/method in such way that
      it also detects cases when field used in key is updated in trigger.
      As nice side-effect we have more precise and thus more optimal
      perfomance-wise check for the MULTI-UPDATE.
      Also check_if_key_used()/QUICK_SELECT_I::check_if_keys_used() were
      renamed to is_key_used()/QUICK_SELECT_I::is_keys_used() in order to
      better reflect that boolean predicate.
      
      Note that this check is implemented in much more elegant way in 5.1 
      091ed9fb
  10. 24 Aug, 2006 1 commit
  11. 17 Aug, 2006 1 commit
    • andrey@example.com's avatar
      Cleanup patch. · 081b8659
      andrey@example.com authored
      There is an existing macros for initializing LEX_STRINGs
      with constant strings -> C_STRING_WITH_LEN. Change existing code to use it.
      (char *) STRING_WITH_LEN -> C_STRING_WITH_LEN
      081b8659
  12. 14 Aug, 2006 1 commit
  13. 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
  14. 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
  15. 13 Jul, 2006 1 commit
    • kroki/tomash@moonlight.intranet's avatar
      Bug#18630: Arguments of suid routine calculated in wrong security · 4272d1ef
      kroki/tomash@moonlight.intranet authored
                 context.
      
      Routine arguments were evaluated in the security context of the routine
      itself, not in the caller's context.
      
      The bug is fixed the following way:
      
        - Item_func_sp::find_and_check_access() has been split into two
          functions: Item_func_sp::find_and_check_access() itself only
          finds the function and check that the caller have EXECUTE privilege
          on it.  New function set_routine_security_ctx() changes security
          context for SUID routines and checks that definer have EXECUTE
          privilege too.
      
        - new function sp_head::execute_trigger() is called from
          Table_triggers_list::process_triggers() instead of
          sp_head::execute_function(), and is effectively just as the
          sp_head::execute_function() is, with all non-trigger related code
          removed, and added trigger-specific security context switch.
      
        - call to Item_func_sp::find_and_check_access() stays outside
          of sp_head::execute_function(), and there is a code in
          sql_parse.cc before the call to sp_head::execute_procedure() that
          checks that the caller have EXECUTE privilege, but both
          sp_head::execute_function() and sp_head::execute_procedure() call
          set_routine_security_ctx() after evaluating their parameters,
          and restore the context after the body is executed.
      4272d1ef
  16. 06 Jul, 2006 1 commit
    • 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
  17. 01 Jul, 2006 1 commit
    • dlenev@mysql.com's avatar
      Fix for bug#18437 "Wrong values inserted with a before update trigger on · d4450e66
      dlenev@mysql.com authored
      NDB table".
      
      SQL-layer was not marking fields which were used in triggers as such. As
      result these fields were not always properly retrieved/stored by handler
      layer. So one might got wrong values or lost changes in triggers for NDB,
      Federated and possibly InnoDB tables.
      This fix solves the problem by marking fields used in triggers
      appropriately.
      
      Also this patch contains the following cleanup of ha_ndbcluster code:
      
      We no longer rely on reading LEX::sql_command value in handler in order
      to determine if we can enable optimization which allows us to handle REPLACE
      statement in more efficient way by doing replaces directly in write_row()
      method without reporting error to SQL-layer.
      Instead we rely on SQL-layer informing us whether this optimization
      applicable by calling handler::extra() method with
      HA_EXTRA_WRITE_CAN_REPLACE flag.
      As result we no longer apply this optimzation in cases when it should not
      be used (e.g. if we have on delete triggers on table) and use in some
      additional cases when it is applicable (e.g. for LOAD DATA REPLACE).
      
      Finally this patch includes fix for bug#20728 "REPLACE does not work
      correctly for NDB table with PK and unique index".
        
      This was yet another problem which was caused by improper field mark-up.
      During row replacement fields which weren't explicity used in REPLACE
      statement were not marked as fields to be saved (updated) so they have
      retained values from old row version. The fix is to mark all table
      fields as set for REPLACE statement. Note that in 5.1 we already solve
      this problem by notifying handler that it should save values from all
      fields only in case when real replacement happens.
      d4450e66
  18. 28 Jun, 2006 2 commits
    • kroki@mysql.com's avatar
      Bug#10946: Confusing error messeges in the case of duplicate trigger definition · 3e2e20ec
      kroki@mysql.com authored
      It was hard to distinguish case, when one was unable to create trigger
      on the table because trigger with same action time and event already
      existed for this table, from the case, when one tried to create trigger
      with name which was already occupied by some other trigger, since in
      both these cases we emitted ER_TRG_ALREADY_EXISTS error and message.
      Now we emit ER_NOT_SUPPORTED_YET error with appropriate additional
      message in the first case. There is no sense in introducing separate
      error for this situation since we plan to get rid of this limitation
      eventually.
      3e2e20ec
    • jimw@mysql.com's avatar
      Bug #18005: Creating a trigger on mysql.event leads to server crash on scheduler startup · 5d2c0de5
      jimw@mysql.com authored
      Bug #18361: Triggers on mysql.user table cause server crash
      
       Because they do not work, we do not allow creating triggers on tables
       within the 'mysql' schema.
      
       (They may be made to work and re-enabled at some later date, but not
       in 5.0 or 5.1.)
      5d2c0de5
  19. 26 Jun, 2006 2 commits
    • 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
    • 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
  20. 19 May, 2006 1 commit
  21. 18 May, 2006 1 commit
    • anozdrin@mysql.com's avatar
      This is an implementation of two WL items: · c1113af1
      anozdrin@mysql.com authored
        - WL#3158: IM: Instance configuration extensions;
        - WL#3159: IM: --bootstrap and --start-default-instance modes
      
      The following new statements have been added:
        - CREATE INSTANCE;
        - DROP INSTANCE;
      
      The behaviour of the following statements have been changed:
        - SET;
        - UNSET;
        - FLUSH INSTANCES;
        - SHOW INSTANCES;
        - SHOW INSTANCE OPTIONS;
      c1113af1
  22. 27 Mar, 2006 1 commit
  23. 24 Mar, 2006 1 commit
  24. 10 Mar, 2006 1 commit
  25. 04 Mar, 2006 1 commit
    • dlenev@mysql.com's avatar
      Fix for bug #17866 "Problem with renaming table with triggers with fully · efe09006
      dlenev@mysql.com authored
      qualified subject table" which was introduced during work on bug #13525
      "Rename table does not keep info of triggers".
      
      The bug was caused by the fact that during reconstruction of CREATE TRIGGER
      statement stored in .TRG file which happened during RENAME TABLE we damaged
      trigger definition in case when it contained fully qualified name of subject
      table (see comment for sql_yacc.yy for more info).
      efe09006
  26. 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
  27. 01 Mar, 2006 1 commit
  28. 24 Feb, 2006 1 commit
  29. 13 Feb, 2006 1 commit
  30. 08 Feb, 2006 1 commit
  31. 01 Feb, 2006 1 commit
    • anozdrin@mysql.com's avatar
      Fix for BUG#9412: Triggers: should have trigger privilege. · 0a1f7e92
      anozdrin@mysql.com authored
      Implement table-level TRIGGER privilege to control access to triggers.
      Before this path global SUPER privilege was used for this purpose, that
      was the big security problem.
      
      In details, before this patch SUPER privilege was required:
        - for the user at CREATE TRIGGER time to create a new trigger;
        - for the user at DROP TRIGGER time to drop the existing trigger;
        - for the definer at trigger activation time to execute the trigger (if the
          definer loses SUPER privilege, all its triggers become unavailable);
      
      This patch changes the behaviour in the following way:
        - TRIGGER privilege on the subject table for trigger is required:
          - for the user at CREATE TRIGGER time to create a new trigger;
          - for the user at DROP TRIGGER time to drop the existing trigger;
          - for the definer at trigger activation time to execute the trigger
            (if the definer loses TRIGGER privilege on the subject table, all its
            triggers on this table become unavailable).
        - SUPER privilege is still required:
          - for the user at CREATE TRIGGER time to explicitly set the trigger
            definer to the user other than CURRENT_USER().
      
      When the server works with database of the previous version (w/o TRIGGER
      privilege), or if the database is being upgraded from the previous versions,
      TRIGGER privilege is granted to whose users, who have CREATE privilege.
      0a1f7e92
  32. 24 Jan, 2006 1 commit
    • anozdrin@mysql.com's avatar
      Fix for the following bugs: · 378147a2
      anozdrin@mysql.com authored
        - BUG#15166: Wrong update permissions required to execute triggers
        - BUG#15196: Wrong select permission required to execute triggers
      
      The idea of the fix is to check necessary privileges
      in Item_trigger_field::fix_fields(), instead of having "special variables"
      technique. To achieve this, we should pass to an Item_trigger_field instance
      a flag, which will indicate the usage/access type of this trigger variable.
      378147a2
  33. 10 Jan, 2006 1 commit
  34. 06 Jan, 2006 1 commit
  35. 05 Jan, 2006 1 commit
    • monty@mysql.com's avatar
      Review fixes of new pushed code · 6e22e29d
      monty@mysql.com authored
      - Fixed tests
      - Optimized new code
      - Fixed some unlikely core dumps
      - Better bug fixes for:
        - #14397 - OPTIMIZE TABLE with an open HANDLER causes a crash
        - #14850 (ERROR 1062 when a quering a view using a Group By on a column that can be null
      6e22e29d
  36. 31 Dec, 2005 1 commit
    • bar@mysql.com's avatar
      WL#1324 table name to file name encoding · 6ff21132
      bar@mysql.com authored
      - Encoding itself, implemented as a charset
        "filename". Originally planned to use '.'
        as an escape character, but now changed to '@'
        for two reasons: "ls" does not return
        file names starting with '.' considering them
        as a kind of hidden files; some platforms
        do not allow several dots in a file name.
      - replacing many calls of my_snprintf() and
        strnxmov() to the new build_table_filename().
      - Adding MY_APPEND_EXT mysys flag, to append
        an extention rather that replace it.
      - Replacing all numeric constants in fn_format
        flag arguments to their mysys definitions, e.g.
        MY_UNPACK_FILENAME,
      - Predictability in several function/methods:
        when a table name can appear with or withot .frm
        extension. Some functions/methods were changed
        so accept names strictly with .frm, other - strictly
        without .frm extensions. Several DBUG_ASSERTs were
        added to check whether an extension is passed.
      Many files:
        table name to file name encoding
      mysql_priv.h:
        Prototypes for new table name encoding tools.
      ctype-utf8.c:
        Implementing "filename" charset for
        table name to file name encoding.
      row0mysql.c:
        Fixing table name prefix.
      mf_format.c:
        Adding MY_APPEND_EXT processing.
      Many files:
        Fixing tests.
      my_sys.h:
        Adding new flag to append rather than replace an extension.
      m_ctype.h:
        Adding "filename" charset definition.
      6ff21132
  37. 21 Dec, 2005 1 commit