An error occurred fetching the project authors.
  1. 02 Apr, 2007 1 commit
  2. 28 Mar, 2007 1 commit
    • tsmith@siva.hindu.god's avatar
      Bug #26642: create index corrupts table definition in .frm · ecd22993
      tsmith@siva.hindu.god authored
      Thanks to Martin Friebe for finding and submitting a fix for this bug!
      
      A table with maximum number of key segments and maximum length key name
      would have a corrupted .frm file, due to an incorrect calculation of the
      complete key length.  Now the key length is computed correctly (I hope) :-)
      
      MyISAM would reject a table with the maximum number of keys and the maximum
      number of key segments in all keys.  It would allow one less than this total
      maximum.  Now MyISAM accepts a table defined with the maximum.  (This is a
      very minor issue.)
      ecd22993
  3. 16 Mar, 2007 1 commit
  4. 11 Mar, 2007 1 commit
    • gkodinov/kgeorge@magare.gmz's avatar
      WL3527: post-merge updates · a474f334
      gkodinov/kgeorge@magare.gmz authored
      sql_yacc.yy:
        WL3527: updated the diff to use correct parser words
      table.cc:
        WL3527: exteneded the fix for bug #20604 to fit the new variables
      sql_select.cc:
        WL3527: renamed used_keys to covering_keys
      a474f334
  5. 09 Mar, 2007 1 commit
    • kroki/tomash@moonlight.home's avatar
      BUG#9953: CONVERT_TZ requires mysql.time_zone_name to be locked · c19affef
      kroki/tomash@moonlight.home authored
      The problem was that some facilities (like CONVERT_TZ() function or
      server HELP statement) may require implicit access to some tables in
      'mysql' database.  This access was done by ordinary means of adding
      such tables to the list of tables the query is going to open.
      However, if we issued LOCK TABLES before that, we would get "table
      was not locked" error trying to open such implicit tables.
      
      The solution is to treat certain tables as MySQL system tables, like
      we already do for mysql.proc.  Such tables may be opened for reading
      at any moment regardless of any locks in effect.  The cost of this is
      that system table may be locked for writing only together with other
      system tables, it is disallowed to lock system tables for writing and
      have any other lock on any other table.
      
      After this patch the following tables are treated as MySQL system
      tables:
        mysql.help_category
        mysql.help_keyword
        mysql.help_relation
        mysql.help_topic
        mysql.proc (it already was)
        mysql.time_zone
        mysql.time_zone_leap_second
        mysql.time_zone_name
        mysql.time_zone_transition
        mysql.time_zone_transition_type
      
      These tables are now opened with open_system_tables_for_read() and
      closed with close_system_tables(), or one table may be opened with
      open_system_table_for_update() and closed with close_thread_tables()
      (the latter is used for mysql.proc table, which is updated as part of
      normal MySQL server operation).  These functions may be used when
      some tables were opened and locked already.
      
      NOTE: online update of time zone tables is not possible during
      replication, because there's no time zone cache flush neither on LOCK
      TABLES, nor on FLUSH TABLES, so the master may serve stale time zone
      data from cache, while on slave updated data will be loaded from the
      time zone tables.
      c19affef
  6. 06 Mar, 2007 1 commit
    • malff/marcsql@weblab.(none)'s avatar
      Bug#8407 (Stored functions/triggers ignore exception handler) · b216d959
      malff/marcsql@weblab.(none) authored
      Bug 18914 (Calling certain SPs from triggers fail)
      Bug 20713 (Functions will not not continue for SQLSTATE VALUE '42S02')
      Bug 21825 (Incorrect message error deleting records in a table with a
        trigger for inserting)
      Bug 22580 (DROP TABLE in nested stored procedure causes strange dependency
        error)
      Bug 25345 (Cursors from Functions)
      
      
      This fix resolves a long standing issue originally reported with bug 8407,
      which affect the behavior of Stored Procedures, Stored Functions and Trigger
      in many different ways, causing symptoms reported by all the bugs listed.
      In all cases, the root cause of the problem traces back to 8407 and how the
      server locks tables involved with sub statements.
      
      Prior to this fix, the implementation of stored routines would:
      - compute the transitive closure of all the tables referenced by a top level
      statement
      - open and lock all the tables involved
      - execute the top level statement
      "transitive closure of tables" means collecting:
      - all the tables,
      - all the stored functions,
      - all the views,
      - all the table triggers
      - all the stored procedures
      involved, and recursively inspect these objects definition to find more
      references to more objects, until the list of every object referenced does
      not grow any more.
      This mechanism is known as "pre-locking" tables before execution.
      The motivation for locking all the tables (possibly) used at once is to
      prevent dead locks.
      
      One problem with this approach is that, if the execution path the code
      really takes during runtime does not use a given table, and if the table is
      missing, the server would not execute the statement.
      This in particular has a major impact on triggers, since a missing table
      referenced by an update/delete trigger would prevent an insert trigger to run.
      
      Another problem is that stored routines might define SQL exception handlers
      to deal with missing tables, but the server implementation would never give
      user code a chance to execute this logic, since the routine is never
      executed when a missing table cause the pre-locking code to fail.
      
      With this fix, the internal implementation of the pre-locking code has been
      relaxed of some constraints, so that failure to open a table does not
      necessarily prevent execution of a stored routine.
      
      In particular, the pre-locking mechanism is now behaving as follows:
      
      1) the first step, to compute the transitive closure of all the tables
      possibly referenced by a statement, is unchanged.
      
      2) the next step, which is to open all the tables involved, only attempts
      to open the tables added by the pre-locking code, but silently fails without
      reporting any error or invoking any exception handler is the table is not
      present. This is achieved by trapping internal errors with
      Prelock_error_handler
      
      3) the locking step only locks tables that were successfully opened.
      
      4) when executing sub statements, the list of tables used by each statements
      is evaluated as before. The tables needed by the sub statement are expected
      to be already opened and locked. Statement referencing tables that were not
      opened in step 2) will fail to find the table in the open list, and only at
      this point will execution of the user code fail.
      
      5) when a runtime exception is raised at 4), the instruction continuation
      destination (the next instruction to execute in case of SQL continue
      handlers) is evaluated.
      This is achieved with sp_instr::exec_open_and_lock_tables()
      
      6) if a user exception handler is present in the stored routine, that
      handler is invoked as usual, so that ER_NO_SUCH_TABLE exceptions can be
      trapped by stored routines. If no handler exists, then the runtime execution
      will fail as expected.
      
      With all these changes, a side effect is that view security is impacted, in
      two different ways.
      
      First, a view defined as "select stored_function()", where the stored
      function references a table that may not exist, is considered valid.
      The rationale is that, because the stored function might trap exceptions
      during execution and still return a valid result, there is no way to decide
      when the view is created if a missing table really cause the view to be invalid.
      
      Secondly, testing for existence of tables is now done later during
      execution. View security, which consist of trapping errors and return a
      generic ER_VIEW_INVALID (to prevent disclosing information) was only
      implemented at very specific phases covering *opening* tables, but not
      covering the runtime execution. Because of this existing limitation,
      errors that were previously trapped and converted into ER_VIEW_INVALID are
      not trapped, causing table names to be reported to the user.
      This change is exposing an existing problem, which is independent and will
      be resolved separately.
      b216d959
  7. 05 Mar, 2007 1 commit
    • gkodinov/kgeorge@macbook.gmz's avatar
      WL#3527: Extend IGNORE INDEX so places where index is ignored · b9c82eaa
      gkodinov/kgeorge@macbook.gmz authored
               can be specified
      Currently MySQL allows one to specify what indexes to ignore during
      join optimization. The scope of the current USE/FORCE/IGNORE INDEX 
      statement is only the FROM clause, while all other clauses are not 
      affected.
      
      However, in certain cases, the optimizer
      may incorrectly choose an index for sorting and/or grouping, and
      produce an inefficient query plan.
      
      This task provides the means to specify what indexes are
      ignored/used for what operation in a more fine-grained manner, thus
      making it possible to manually force a better plan. We do this
      by extending the current IGNORE/USE/FORCE INDEX syntax to:
      
      IGNORE/USE/FORCE INDEX [FOR {JOIN | ORDER | GROUP BY}]
      
      so that:
      - if no FOR is specified, the index hint will apply everywhere.
      - if MySQL is started with the compatibility option --old_mode then
        an index hint without a FOR clause works as in 5.0 (i.e, the 
        index will only be ignored for JOINs, but can still be used to
        compute ORDER BY).
      
      See the WL#3527 for further details.
      b9c82eaa
  8. 28 Feb, 2007 1 commit
  9. 12 Feb, 2007 2 commits
    • tnurnberg@mysql.com/sin.azundris.com's avatar
      Bug#24660: "enum" field type definition problem · db7ac2c0
      tnurnberg@mysql.com/sin.azundris.com authored
      ENUMs weren't allowed to have character 0xff, a perfectly good character in some locales.
      This was circumvented by mapping 0xff in ENUMs to ',', thereby prevent actual commas from
      being used. Now if 0xff makes an appearance, we find a character not used in the enum and
      use that as a separator. If no such character exists, we throw an error.
      
      Any solution would have broken some sort of existing behaviour. This solution should
      serve both fractions (those with 0xff and those with ',' in their enums), but
      WILL REQUIRE A DUMP/RESTORE CYCLE FROM THOSE WITH 0xff IN THEIR ENUMS. :-/
      That is, mysqldump with their current server, and restore when upgrading to one with
      this patch.
      db7ac2c0
    • gluh@mysql.com/eagle.(none)'s avatar
      Bug#24630 Subselect query crashes mysqld · 47e537b4
      gluh@mysql.com/eagle.(none) authored
      The crash happens because second filling of the same I_S table happens in
      case of subselect with order by. table->sort.io_cache previously allocated
      in create_sort_index() is deleted during second filling
      (function get_schema_tables_result). There are two places where
      I_S table can be filled: JOIN::exec and create_sort_index().
      To fix the bug we should check if the table was already filled
      in one of these places and skip processing of the table in second.
      47e537b4
  10. 31 Jan, 2007 1 commit
    • gkodinov/kgeorge@macbook.gmz's avatar
      BUG#25575: ERROR 1052 (Column in from clause is ambiguous) with sub-join · 16d2d682
      gkodinov/kgeorge@macbook.gmz authored
       Two problems here:
      
       Problem 1:
      
       While constructing the join columns list the optimizer does as follows:
        1. Sets the join_using_fields/natural_join members of the right JOIN 
         operand.
        2. Makes a "table reference" (TABLE_LIST) to parent the two tables.
        3. Assigns the join_using_fields/is_natural_join of the wrapper table
         using join_using_fields/natural_join of the rightmost table
        4. Sets join_using_fields to NULL for the right JOIN operand.
        5. Passes the parent table up to the same procedure on the upper 
         level.
      
       Step 1 overrides the the join_using_fields that are set for a nested 
       join wrapping table in step 4.
       Fixed by making a designated variable SELECT_LEX::prev_join_using to 
       pass the data from step 1 to step 4 without destroying the wrapping 
       table data.
      
       Problem 2:
      
       The optimizer checks for ambiguous columns while transforming 
       NATURAL JOIN/JOIN USING to JOIN ON. While doing that there was no
       distinction between columns that are used in the generated join
       condition (where ambiguity can be checked) and the other columns
       (where ambiguity can be checked only when resolving references
       coming from outside the JOIN construct itself).
       Fixed by allowing the non-USING columns to be present in multiple 
       copies in both sides of the join and moving the ambiguity check 
       to the place where unqualified references to the join columns are
       resolved (find_field_in_natural_join()).
      16d2d682
  11. 29 Jan, 2007 1 commit
  12. 28 Jan, 2007 1 commit
    • monty@mysql.com/narttu.mysql.fi's avatar
      After merge fixes · 410fc81a
      monty@mysql.com/narttu.mysql.fi authored
      Removed a lot of compiler warnings
      Removed not used variables, functions and labels
      Initialize some variables that could be used unitialized (fatal bugs)
      %ll -> %l
      410fc81a
  13. 22 Jan, 2007 1 commit
  14. 12 Jan, 2007 1 commit
    • tnurnberg@mysql.com/sin.azundris.com's avatar
      Bug#24660: "enum" field type definition problem · 90a80926
      tnurnberg@mysql.com/sin.azundris.com authored
      ENUMs weren't allowed to have character 0xff, a perfectly good
      character in some locales.  This was circumvented by mapping 0xff in
      ENUMs to ',', thereby prevent actual commas from being used. Now if
      0xff makes an appearance, we find a character not used in the enum and
      use that as a separator. If no such character exists, we throw an
      error.
      
      Any solution would have broken some sort of existing behaviour. This
      solution should serve both fractions (those with 0xff and those with
      ',' in their enums), but WILL REQUIRE A DUMP/RESTORE CYCLE FROM THOSE
      WITH 0xff IN THEIR ENUMS. :-/ That is, mysqldump with their current
      server, and restore when upgrading to one with this patch.
      90a80926
  15. 09 Jan, 2007 1 commit
    • tnurnberg@mysql.com/sin.azundris.com's avatar
      Bug#24660: "enum" field type definition problem · 34122240
      tnurnberg@mysql.com/sin.azundris.com authored
      ENUMs weren't allowed to have character 0xff, a perfectly good character in many locales.
      This was circumvented by mapping 0xff in ENUMs to ',', thereby prevent actual commas from
      being used (because they too would get converted to 0xff on load). Now if 0xff makes an
      appearance, we find a character not used in the enum and use that as a separator. If no
      such character exists, we throw an error.
      
      Any solution would have broken some sort of existing behaviour. This solution should
      serve both fractions (those with 0xff and those with ',' in their enums), but
      WILL REQUIRE A DUMP/RESTORE CYCLE FROM THOSE WITH 0xff IN THEIR ENUMS. :-/
      That is, mysqldump with their current server, and restore when upgrading to one with
      this patch.
      
      (port of the original 4.1 patch. incorporates some suggestions by kaamos.)
      34122240
  16. 31 Dec, 2006 1 commit
    • kent@mysql.com/kent-amd64.(none)'s avatar
      my_strtoll10-x86.s: · 6523aca7
      kent@mysql.com/kent-amd64.(none) authored
        Corrected spelling in copyright text
      Makefile.am:
        Don't update the files from BitKeeper
      Many files:
        Removed "MySQL Finland AB & TCX DataKonsult AB" from copyright header
        Adjusted year(s) in copyright header 
      Many files:
        Added GPL copyright text
      Removed files:
        Docs/Support/colspec-fix.pl
        Docs/Support/docbook-fixup.pl
        Docs/Support/docbook-prefix.pl
        Docs/Support/docbook-split
        Docs/Support/make-docbook
        Docs/Support/make-makefile
        Docs/Support/test-make-manual
        Docs/Support/test-make-manual-de
        Docs/Support/xwf
      6523aca7
  17. 23 Dec, 2006 1 commit
  18. 15 Dec, 2006 1 commit
    • svoj@mysql.com/april.(none)'s avatar
      BUG#24358 - Table access crashes server · 77085c8e
      svoj@mysql.com/april.(none) authored
      Having broken .frm, particulary number of field names does
      not match number of fields, causes server crash.
      
      Refuse to open a table if number of field names in a table
      is not equal to number of fields in a table.
      
      No test case, since it requires broken .frm file.
      77085c8e
  19. 14 Dec, 2006 1 commit
    • monty@mysql.com/narttu.mysql.fi's avatar
      Fixed compiler warnings detected by option -Wshadow and -Wunused: · 88dd873d
      monty@mysql.com/narttu.mysql.fi authored
      - Removed not used variables and functions
      - Added #ifdef around code that is not used
      - Renamed variables and functions to avoid conflicts
      - Removed some not used arguments
      
      Fixed some class/struct warnings in ndb
      Added define IS_LONGDATA() to simplify code in libmysql.c
      
      I did run gcov on the changes and added 'purecov' comments on almost all lines that was not just variable name changes
      88dd873d
  20. 07 Dec, 2006 1 commit
  21. 02 Dec, 2006 1 commit
  22. 30 Nov, 2006 2 commits
    • aelkin/elkin@dsl-hkibras-fe30f900-107.dhcp.inet.fi's avatar
      Bug #24487 Valgrind: uninited byte in table->record[1] in binlog code for rbr + inno db · 45b6bafe
      The reason of this valgrind's compaint is not a bug but rather a feature of bitwise ops:
      for any value of the byte x
      x | 1 -> 1,  and x & 0 -> 0.
      x, being a null_byte part of record[1] can be left unassigned even after
      ha_innobase::index_read_idx because the above and still be correct.
      Addding a check memory upon the invocation of the function can detect this fact
      long before record[1], old record, is eventually passed to my_write.
      
      Fixed with initialization of record[1]'s null_bytes part in open_table_from_share.
      45b6bafe
    • 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
  23. 28 Nov, 2006 1 commit
  24. 27 Nov, 2006 2 commits
  25. 26 Nov, 2006 2 commits
    • 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
    • aelkin/elkin@dsl-hkibras-fe30f900-107.dhcp.inet.fi's avatar
      Bug #24487 Valgrind: uninited byte in table->record[1] in binlog code for rbr + innodb · c610c271
      The reason of this valgrind's compaint is not a bug but rather a feature of bitwise ops:
      for any value of the byte x
      x | 1 -> 1,  and x & 0 -> 0.
      x, being a null_byte part of record[1] can be left unassigned even after
      ha_innobase::index_read_idx because the above and still be correct.
      Addding a check memory upon the invocation of the function can detect this fact
      long before record[1], old record, is eventually passed to my_write.
      
      Fixed with initialization of record[1]'s null_bytes part in open_table_from_share.
      c610c271
  26. 21 Nov, 2006 2 commits
  27. 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
  28. 17 Nov, 2006 1 commit
  29. 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
  30. 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
  31. 16 Oct, 2006 1 commit
  32. 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
  33. 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