An error occurred fetching the project authors.
  1. 10 Jan, 2007 1 commit
  2. 23 Dec, 2006 1 commit
  3. 07 Dec, 2006 1 commit
    • kostja@bodhi.local's avatar
      A fix and test cases for · 90072e69
      kostja@bodhi.local authored
      Bug#4968 "Stored procedure crash if cursor opened on altered table"
      Bug#19733 "Repeated alter, or repeated create/drop, fails"
      Bug#19182 "CREATE TABLE bar (m INT) SELECT n FROM foo; doesn't work from 
      stored procedure."
      Bug#6895 "Prepared Statements: ALTER TABLE DROP COLUMN does nothing"
      Bug#22060 "ALTER TABLE x AUTO_INCREMENT=y in SP crashes server"
      
      Test cases for bugs 4968, 19733, 6895 will be added in 5.0.
      
      Re-execution of CREATE DATABASE, CREATE TABLE and ALTER TABLE 
      statements in stored routines or as prepared statements caused
      incorrect results (and crashes in versions prior to 5.0.25).
      In 5.1 the problem occured only for CREATE DATABASE, CREATE TABLE
      SELECT and CREATE TABLE with INDEX/DATA DIRECTOY options).
      
      The problem of bugs 4968, 19733, 19282 and 6895 was that functions
      mysql_prepare_table, mysql_create_table and mysql_alter_table were not
      re-execution friendly: during their operation they used to modify contents
      of LEX (members create_info, alter_info, key_list, create_list),
      thus making the LEX unusable for the next execution.
      In particular, these functions removed processed columns and keys from
      create_list, key_list and drop_list. Search the code in sql_table.cc 
      for drop_it.remove() and similar patterns to find evidence.
      
      The fix is to supply to these functions a usable copy of each of the
      above structures at every re-execution of an SQL statement. 
      
      To simplify memory management, LEX::key_list and LEX::create_list
      were added to LEX::alter_info, a fresh copy of which is created for
      every execution.
      
      The problem of crashing bug 22060 stemmed from the fact that the above 
      metnioned functions were not only modifying HA_CREATE_INFO structure in 
      LEX, but also were changing it to point to areas in volatile memory of 
      the execution memory root.
       
      The patch solves this problem by creating and using an on-stack
      copy of HA_CREATE_INFO (note that code in 5.1 already creates and
      uses a copy of this structure in mysql_create_table()/alter_table(),
      but this approach didn't work well for CREATE TABLE SELECT statement).
      90072e69
  4. 05 Dec, 2006 2 commits
  5. 30 Nov, 2006 1 commit
  6. 27 Nov, 2006 1 commit
    • ramil/ram@mysql.com/myoffice.izhnet.ru's avatar
      Fix for bug #21587: FLUSH TABLES causes server crash when used with HANDLER statements · 55aa6e04
      Problems (appear only under some circumstances): 
        1. we get a reference to a deleted table searching in the 
           thd->handler_tables_hash in the mysql_ha_read().
      
        2. DBUG_ASSERT(table->file->inited == handler::NONE); assert fails in the
           close_thread_table().
      
      Fix: end open index scans and table scans and remove references to the 
      tables from the handler tables hash. After this preparation it is safe 
      to close the tables. The close can no longer fail on open index/table 
      scans and the closed table will not be used again by handler functions.
                                       
      55aa6e04
  7. 09 Nov, 2006 1 commit
  8. 01 Nov, 2006 2 commits
    • petr/cps@mysql.com/owlet.local's avatar
      Fix Bug #9191 "TIMESTAMP/from_unixtime() no longer accepts 2^31-1" · 3ec542df
      petr/cps@mysql.com/owlet.local authored
      (4.1 version, with post-review fixes)
        
        The fix for another Bug (6439) limited FROM_UNIXTIME() to
        TIMESTAMP_MAX_VALUE which is 2145916799 or 2037-12-01 23:59:59 GMT,
        however unix timestamp in general is not considered to be limited 
        by this value. All dates up to power(2,31)-1 are valid.
        
        This patch extends allowed TIMESTAMP range so, that max
        TIMESTAMP value is power(2,31)-1. It also corrects
        FROM_UNIXTIME() and UNIX_TIMESTAMP() functions, so that
        max allowed UNIX_TIMESTAMP() is power(2,31)-1. FROM_UNIXTIME()
        is fixed accordingly to allow conversion of dates up to
        2038-01-19 03:14:07 UTC. The patch also fixes CONVERT_TZ()
        function to allow extended range of dates.
        
        The main problem solved in the patch is possible overflows
        of variables, used in broken-time representation to time_t
        conversion (required for UNIX_TIMESTAMP).
      3ec542df
    • 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
  9. 30 Oct, 2006 1 commit
    • kroki/tomash@moonlight.intranet's avatar
      BUG#21915: Changing limits of table_cache when setting max_connections · 1bfe00e0
      kroki/tomash@moonlight.intranet authored
      If the user has specified --max-connections=N or --table-open-cache=M
      options to the server, a warning could be given that some values were
      recalculated, and table-open-cache could be assigned greater value.
      
      Note that both warning and increase of table-open-cache were totally
      harmless.
      
      This patch fixes recalculation code to ensure that table-open-cache will
      be never increased automatically and that a warning will be given only if
      some values had to be decreased due to operating system limits.
      
      No test case is provided because we neither can't predict nor control
      operating system limits for maximal number of open files.
      1bfe00e0
  10. 19 Oct, 2006 1 commit
    • istruewing@chilla.local's avatar
      Bug#21476 - Lost Database Connection During Query · 9b3e7bd0
      istruewing@chilla.local authored
      Backport from 5.1.
      Raised STACK_MIN_SIZE for Debian GNU/Linux Sid,
      Linux kernel 2.6.16,
      gcc version 3.3.6 (Debian 1:3.3.6-13),
      libc6-dbg 2.3.6.ds1-4,
      Pentium4 (x86),
      BUILD/compile-pentium-debug-max
      Raised about 100 Bytes above the required minimum.
      9b3e7bd0
  11. 17 Oct, 2006 1 commit
    • gkodinov/kgeorge@macbook.gmz's avatar
      Bug#21798: memory leak during query execution with subquery in column · f7b89376
      gkodinov/kgeorge@macbook.gmz authored
                  list using a function
      When executing dependent subqueries they are re-inited and re-exec() for 
      each row of the outer context.
      The cause for the bug is that during subquery reinitialization/re-execution,
      the optimizer reallocates JOIN::join_tab, JOIN::table in make_simple_join()
      and the local variable in 'sortorder' in create_sort_index(), which is
      allocated by make_unireg_sortorder().
      Care must be taken not to allocate anything into the thread's memory pool
      while re-initializing query plan structures between subquery re-executions.
      All such items mush be cached and reused because the thread's memory pool
      is freed at the end of the whole query.
      Note that they must be cached and reused even for queries that are not 
      otherwise cacheable because otherwise it will grow the thread's memory 
      pool every time a cacheable query is re-executed. 
      We provide additional members to the JOIN structure to store references 
      to the items that need to be cached.
      f7b89376
  12. 13 Oct, 2006 1 commit
    • evgen@moonbone.local's avatar
      Bug#14959: ALTER TABLE isn't able to rename a view · 2b474898
      evgen@moonbone.local authored
      The mysql_alter_table() was able to rename only a table.
      
      The view/table renaming code is moved from the function rename_tables 
      to the new function called do_rename().
      The mysql_alter_table() function calls it when it needs to rename a view.
      2b474898
  13. 27 Sep, 2006 2 commits
    • cmiller@zippy.cornsilk.net's avatar
      Bug#21476: (Thread stack overrun not caught, causing SEGV) · c0ab40d3
      cmiller@zippy.cornsilk.net authored
      The STACK_MIN_SIZE is currently set to 8192, when we actually need 
      (emperically discovered) 9236 bytes to raise an fatal error, on Ubuntu 
      Dapper Drake, libc6 2.3.6-0ubuntu2, Linux kernel 2.6.15-27-686, on x86.
      
      I'm taking that as a new lower bound, plus 100B of wiggle-room for sundry
      word sizes and stack behaviors.
      
      The added test verifies in a cross-platform way that there are no gaps 
      between the space that we think we need and what we actually need to report 
      an error.
      
      DOCUMENTERS:  This also adds "let" to the mysqltest commands that evaluate
      an argument to expand variables therein.  (Only right of the "=", of course.)
      c0ab40d3
    • gluh@mysql.com/gluh.(none)'s avatar
      additional 'after merge' fix · 4aaf7e34
      gluh@mysql.com/gluh.(none) authored
      4aaf7e34
  14. 25 Sep, 2006 1 commit
    • igor@rurik.mysql.com's avatar
      Fixed bug #21646. · a661bdda
      igor@rurik.mysql.com authored
      Presence of a subquery in the ON expression of a join 
      should not block merging the view that contains this join.
      Before this patch the such views were converted into 
      into temporary table views.
      a661bdda
  15. 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
  16. 12 Sep, 2006 1 commit
    • kroki/tomash@moonlight.intranet's avatar
      BUG#21414: SP: Procedure undroppable, to some extent · ed0cb3e4
      kroki/tomash@moonlight.intranet authored
      The problem was that if after FLUSH TABLES WITH READ LOCK the user
      issued DROP/ALTER PROCEDURE/FUNCTION the operation would fail (as
      expected), but after UNLOCK TABLE any attempt to execute the same
      operation would lead to the error 1305 "PROCEDURE/FUNCTION does not
      exist", and an attempt to execute any stored function will also fail.
      
      This happened because under FLUSH TABLES WITH READ LOCK we couldn't open
      and lock mysql.proc table for update, and this fact was erroneously
      remembered by setting mysql_proc_table_exists to false, so subsequent
      statements believed that mysql.proc doesn't exist, and thus that there
      are no functions and procedures in the database.
      
      As a solution, we remove mysql_proc_table_exists flag completely.  The
      reason is that this optimization didn't work most of the time anyway.
      Even if open of mysql.proc failed for some reason when we were trying to
      call a function or a procedure, we were setting mysql_proc_table_exists
      back to true to force table reopen for the sake of producing the same
      error message (the open can fail for number of reasons).  The solution
      could have been to remember the reason why open failed, but that's a lot
      of code for optimization of a rare case.  Hence we simply remove this
      optimization.
      ed0cb3e4
  17. 08 Sep, 2006 1 commit
  18. 04 Sep, 2006 1 commit
    • gkodinov/kgeorge@macbook.gmz's avatar
      Bug #21392: multi-table delete with alias table name fails with · 3758b975
      gkodinov/kgeorge@macbook.gmz authored
                  1003: Incorrect table name
      in multi-table DELETE the set of tables to delete from actually 
      references then tables in the other list, e.g:
      DELETE alias_of_t1 FROM t1 alias_of_t1 WHERE ....
      is a valid statement.
      So we must turn off table name syntactical validity check for alias_of_t1 
      because it's not a table name (even if it looks like one).
      In order to do that we add a special flag (TL_OPTION_ALIAS) to 
      disable the name checking for the aliases in multi-table DELETE.
      3758b975
  19. 24 Aug, 2006 1 commit
  20. 23 Aug, 2006 1 commit
  21. 22 Aug, 2006 1 commit
  22. 21 Aug, 2006 1 commit
  23. 19 Aug, 2006 1 commit
  24. 17 Aug, 2006 1 commit
  25. 15 Aug, 2006 1 commit
    • evgen@sunlight.local's avatar
      Fixed bug#21261: Wrong access rights was required for an insert into a view · dd9a0770
      evgen@sunlight.local authored
      SELECT right instead of INSERT right was required for an insert into to a view.
      This wrong behaviour appeared after the fix for bug #20989. Its intention was
      to ask only SELECT right for all tables except the very first for a complex
      INSERT query. But that patch has done it in a wrong way and lead to asking 
      a wrong access right for an insert into a view.
      
      The setup_tables_and_check_access() function now accepts two want_access
      parameters. One will be used for the first table and the second for other
      tables.
      dd9a0770
  26. 28 Jul, 2006 1 commit
    • kroki/tomash@moonlight.intranet's avatar
      Bug#16581: deadlock: server and client both read from connection in · d06001b1
      kroki/tomash@moonlight.intranet authored
                 'conc_sys' test
      
      Concurrent execution of SELECT involing at least two INFORMATION_SCHEMA
      tables, DROP DATABASE statement and DROP TABLE statement could have
      resulted in stalled connection for this SELECT statement.
      
      The problem was that for the first query of a join there was a race
      between select from I_S.TABLES and DROP DATABASE, and the error (no
      such database) was prepared to be send to the client, but the join
      processing was continued.  On second query to I_S.COLUMNS there was a
      race with DROP TABLE, but this error (no such table) was downgraded to
      warning, and thd->net.report_error was reset.  And so neither result
      nor error was sent to the client.
      
      The solution is to stop join processing once it is clear we are going
      to report a error, and also to downgrade to warnings file system errors
      like 'no such database' (unless we are in the 'SHOW' command), because
      I_S is designed not to use locks and the query to I_S should not abort
      if something is dropped in the middle.
      
      No test case is provided since this bug is a result of a race, and is
      timing dependant.  But we test that plain SHOW TABLES and SHOW COLUMNS
      give a error if there is no such database or a table respectively.
      d06001b1
  27. 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
  28. 22 Jul, 2006 1 commit
  29. 21 Jul, 2006 1 commit
  30. 20 Jul, 2006 2 commits
  31. 14 Jul, 2006 1 commit
  32. 04 Jul, 2006 1 commit
  33. 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
  34. 29 Jun, 2006 1 commit
  35. 26 Jun, 2006 1 commit
    • ingo@mysql.com's avatar
      Bug#16986 - Deadlock condition with MyISAM tables · d27a15a8
      ingo@mysql.com authored
      Addendum fixes after changing the condition variable
      for the global read lock.
      
      The stress test suite revealed some deadlocks. Some were
      related to the new condition variable (COND_global_read_lock)
      and some were general problems with the global read lock.
      
      It is now necessary to signal COND_global_read_lock whenever 
      COND_refresh is signalled.
      
      We need to wait for the release of a global read lock if one 
      is set before every operation that requires a write lock.
      But we must not wait if we have locked tables by LOCK TABLES.
      After setting a global read lock a thread waits until all
      write locks are released.
      d27a15a8
  36. 21 Jun, 2006 1 commit
    • gkodinov@mysql.com's avatar
      Bug #20482: failure on Create join view with sources views/tables in different · 75ca0554
      gkodinov@mysql.com authored
                  schemas
      The function check_one_table_access() called to check access to tables in 
      SELECT/INSERT/UPDATE was doing additional checks/modifications that don't hold
      in the context of setup_tables_and_check_access().
      That's why the check_one_table() was split into two : the functionality needed by
      setup_tables_and_check_access() into check_single_table_access() and the rest of 
      the functionality stays in check_one_table_access() that is made to call the new
      check_single_table_access() function.
      75ca0554